Subject: Re: Order status

From: <[email-masked]>
Date: Sat, 29 Aug 2009 14:56:36 -0700 (PDT)

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n7KH9Yan026508 for ; Thu, 20 Aug 2009 19:09:34 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n7KH9YEm013293 for ietf-provreg-outgoing; Thu, 20 Aug 2009 19:09:34 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.130]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n7KH9WWb005348 for ; Thu, 20 Aug 2009 19:09:33 +0200 (MEST)
Received: from limpet.local (cpe-67-241-43-7.twcny.res.rr.com [67.241.43.7]) by abenaki.wabanaki.net (8.14.3/8.14.3) with ESMTP id n7KH62KL092061; Thu, 20 Aug 2009 13:06:03 -0400 (EDT) (envelope-from [email-masked])
Message-ID: <[email-masked]>
Date: Thu, 20 Aug 2009 13:09:25 -0400
From: Eric Brunner-Williams
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: Francisco Obispo
CC: "Hollenbeck, Scott" , [email-masked]
Subject: Re: [ietf-provreg] FW: Protocol Action: 'Extensible Provisioning Protocol (EPP) Transportover TCP' to Full Standard
References: <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

+1

Francisco Obispo wrote:
> Congratulations,!!..
>
> Good job!.
>
> Francisco
>
>
> On Aug 20, 2009, at 8:02 AM, Hollenbeck, Scott wrote:
>
>> 4934bis has been approved by the IESG. That's the last of the document
>> updates for Full Standard. An updated implementation report can be
>> found here:
>>
>> http://www.ietf.org/iesg/implementation/report-rfc4930-4934.txt
>>
>> Thanks to everyone who helped move this forward.
>>
>> -Scott-
>>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of The IESG
>> Sent: Wednesday, August 19, 2009 4:01 PM
>> To: IETF-Announce
>> Cc: Internet Architecture Board; RFC Editor
>> Subject: Protocol Action: 'Extensible Provisioning Protocol (EPP)
>> Transportover TCP' to Full Standard
>>
>> The IESG has approved the following document:
>>
>> - 'Extensible Provisioning Protocol (EPP) Transport over TCP '
>> as a Full Standard
>>
>> This document has been reviewed in the IETF but is not the product of an
>> IETF Working Group.
>>
>> The IESG contact person is Alexey Melnikov.
>>
>> A URL of this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-hollenbeck-rfc4934bis-01.txt
>>
>> Technical Summary
>> This set of documents advances EPP to Standard. References
>> have been updated and non-normative text updates have been made.
>> Some clarifications on TLS server sertificate verification were done.
>>
>> Working Group Summary
>> This is the product of an individual submitter, though the working
>> group mailing list of PROVREG (now closed) was used to review the
>> updates to the documents.
>>
>> Document Quality
>> Issues raised by AD review were addressed.
>> There are multiple implementations of the protocol, as described in
>> the implementation report.
>>
>> Personnel
>> Edward Lewis is the document shepherd for this series
>> (draft-hollenbeck-rfc493*bis) of documents.
>> Alexey Melnikov is the responsible Area Director.
>>
>> RFC Editor note:
>>
>> In Section 9, insert a new paragraph after the paragraph starting with
>> "If the server identity check fails". (The new paragraph would be 3rd to
>> the last):
>>
>> During the TLS negotiation, the EPP server MUST verify that the client
>> certificate matches the reference identity previously negotiated out of
>> band, as specified in section 8. The server should match the entire
>> subject name or the subjectAltName as described in RFC 5280. The server
>> MAY enforce other restrictions on the subjectAltName, for example if it
>> knows that a particular client is always connecting from a particular
>> hostname/IP address.
>>
>> _______________________________________________
>> IETF-Announce mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>
>> List run by majordomo software. For (Un-)subscription and similar
>> details
>> send "help" to [email-masked]
>>
>>
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
> List run by majordomo software. For (Un-)subscription and similar
> details
> send "help" to [email-masked]
>
>
>

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n7KGVamf008266 for ; Thu, 20 Aug 2009 18:31:36 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n7KGVawJ005099 for ietf-provreg-outgoing; Thu, 20 Aug 2009 18:31:36 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from smtp.cenit.gob.ve (smtp.cenit.gob.ve [150.188.4.71]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n7KGVYXq010151 for ; Thu, 20 Aug 2009 18:31:35 +0200 (MEST)
Received: from [150.186.201.2] (unknown [150.186.201.2]) by smtp.cenit.gob.ve (Postfix) with ESMTP id 0C5A83ED5; Thu, 20 Aug 2009 12:07:20 -0430 (VET)
Cc:
Message-Id: <[email-masked]>
From: Francisco Obispo
To: "Hollenbeck, Scott"
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: [ietf-provreg] FW: Protocol Action: 'Extensible Provisioning Protocol (EPP) Transportover TCP' to Full Standard
Date: Thu, 20 Aug 2009 12:01:32 -0430
References: <[email-masked]>
X-Mailer: Apple Mail (2.935.3)
Sender: [email-masked]
Precedence: bulk

Congratulations,!!..

Good job!.

Francisco

On Aug 20, 2009, at 8:02 AM, Hollenbeck, Scott wrote:

> 4934bis has been approved by the IESG. That's the last of the
> document
> updates for Full Standard. An updated implementation report can be
> found here:
>
> http://www.ietf.org/iesg/implementation/report-rfc4930-4934.txt
>
> Thanks to everyone who helped move this forward.
>
> -Scott-
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of The IESG
> Sent: Wednesday, August 19, 2009 4:01 PM
> To: IETF-Announce
> Cc: Internet Architecture Board; RFC Editor
> Subject: Protocol Action: 'Extensible Provisioning Protocol (EPP)
> Transportover TCP' to Full Standard
>
> The IESG has approved the following document:
>
> - 'Extensible Provisioning Protocol (EPP) Transport over TCP '
> as a Full Standard
>
> This document has been reviewed in the IETF but is not the product
> of an
> IETF Working Group.
>
> The IESG contact person is Alexey Melnikov.
>
> A URL of this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hollenbeck-rfc4934bis-01.txt
>
> Technical Summary
> This set of documents advances EPP to Standard. References
> have been updated and non-normative text updates have been made.
> Some clarifications on TLS server sertificate verification were done.
>
> Working Group Summary
> This is the product of an individual submitter, though the working
> group mailing list of PROVREG (now closed) was used to review the
> updates to the documents.
>
> Document Quality
> Issues raised by AD review were addressed.
> There are multiple implementations of the protocol, as described in
> the implementation report.
>
> Personnel
> Edward Lewis is the document shepherd for this series
> (draft-hollenbeck-rfc493*bis) of documents.
> Alexey Melnikov is the responsible Area Director.
>
> RFC Editor note:
>
> In Section 9, insert a new paragraph after the paragraph starting with
> "If the server identity check fails". (The new paragraph would be
> 3rd to
> the last):
>
> During the TLS negotiation, the EPP server MUST verify that the client
> certificate matches the reference identity previously negotiated out
> of
> band, as specified in section 8. The server should match the entire
> subject name or the subjectAltName as described in RFC 5280. The
> server
> MAY enforce other restrictions on the subjectAltName, for example if
> it
> knows that a particular client is always connecting from a particular
> hostname/IP address.
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> =-=-=-
> List run by majordomo software. For (Un-)subscription and similar
> details
> send "help" to [email-masked]
>
>

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n7KF1sQH001871 for ; Thu, 20 Aug 2009 17:01:54 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n7KF1s2f001066 for ietf-provreg-outgoing; Thu, 20 Aug 2009 17:01:54 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n7KF1rOw029470 for ; Thu, 20 Aug 2009 17:01:53 +0200 (MEST)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id n7KEmOZP008334; Thu, 20 Aug 2009 10:48:25 -0400
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 16:01:51 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [ietf-provreg] FW: Protocol Action: 'Extensible ProvisioningProtocol (EPP) Transportover TCP' to Full Standard
Date: Thu, 20 Aug 2009 11:01:46 -0400
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-provreg] FW: Protocol Action: 'Extensible ProvisioningProtocol (EPP) Transportover TCP' to Full Standard
Thread-Index: AcohpSwm35cL+Y+CQcmHsnxZMvyD4gAAejig
References: <[email-masked]> <[email-masked]>
From: "Hollenbeck, Scott"
To: "Patrick Mevzek" ,
X-OriginalArrivalTime: 20 Aug 2009 15:01:51.0517 (UTC) FILETIME=[260DBCD0:01CA21A7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n7KF1rOw013061
Sender: [email-masked]
Precedence: bulk

I just sent an updated report to the Secretariat for posting.

-Scott-

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Patrick Mevzek
> Sent: Thursday, August 20, 2009 10:14 AM
> To: [email-masked]
> Subject: Re: [ietf-provreg] FW: Protocol Action: 'Extensible
> ProvisioningProtocol (EPP) Transportover TCP' to Full Standard
>
> Hello Scott,
>
> Hollenbeck, Scott 2009-08-20 15:10
> > 4934bis has been approved by the IESG. That's the last of the
> > document updates for Full Standard. An updated
> implementation report
> > can be found here:
> >
> > http://www.ietf.org/iesg/implementation/report-rfc4930-4934.txt
> >
> > Thanks to everyone who helped move this forward.
>
> Thanks for your work.
>
> If it is still possible (and if not that is no big deal), can
> you make the following changes:
> - use the From: email address used here for me in the document
>
> and for EPP TLDs:
> - update .FR as it is used in production now (since March) (I
> do not know for .SI, I think they are in production too, same for .NO)
> - add: .NL (being developed)
> - add: .IT
> - add: .CO.CZ (status unknown)
>
>
>
> --
> Patrick Mevzek
> Dot and Co
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> -=-=-=-=-=-=-
> List run by majordomo software. For (Un-)subscription and
> similar details send "help" to [email-masked]
>
>

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n7KEE6Ye001203 for ; Thu, 20 Aug 2009 16:14:06 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n7KEE6tm018459 for ietf-provreg-outgoing; Thu, 20 Aug 2009 16:14:06 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.dotandco.com (triglav.dotandco.com [194.242.114.22]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n7KEE5Nx011703 for ; Thu, 20 Aug 2009 16:14:05 +0200 (MEST)
Received: from triglav.dotandco.com (localhost.localdomain [127.0.0.1]) by mail.dotandco.com (8.13.8/8.13.8/Debian-3) with ESMTP id n7KEE5Th015383; Thu, 20 Aug 2009 16:14:05 +0200
Received: from localhost (localhost [[UNIX: localhost]]) by triglav.dotandco.com (8.13.8/8.13.8/Submit) id n7KEE4dW015382; Thu, 20 Aug 2009 16:14:04 +0200
X-Authentication-Warning: triglav.dotandco.com: patrick set sender to [email-masked] using -f
Date: Thu, 20 Aug 2009 16:14:04 +0200
From: Patrick Mevzek
To: [email-masked]
Subject: Re: [ietf-provreg] FW: Protocol Action: 'Extensible Provisioning Protocol (EPP) Transportover TCP' to Full Standard
Message-ID: <[email-masked]>
References: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
Organization: Dot And Co
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (mail.dotandco.com [127.0.0.1]); Thu, 20 Aug 2009 16:14:05 +0200 (CEST)
Sender: [email-masked]
Precedence: bulk

Hello Scott,

Hollenbeck, Scott 2009-08-20 15:10
> 4934bis has been approved by the IESG. That's the last of the document
> updates for Full Standard. An updated implementation report can be
> found here:
>
> http://www.ietf.org/iesg/implementation/report-rfc4930-4934.txt
>
> Thanks to everyone who helped move this forward.

Thanks for your work.

If it is still possible (and if not that is no big deal), can you
make the following changes:
- use the From: email address used here for me in the document

and for EPP TLDs:
- update .FR as it is used in production now (since March)
(I do not know for .SI, I think they are in production too,
same for .NO)
- add: .NL (being developed)
- add: .IT
- add: .CO.CZ (status unknown)

--
Patrick Mevzek
Dot and Co
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n7KCWjf5023204 for ; Thu, 20 Aug 2009 14:32:45 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n7KCWjlj023630 for ietf-provreg-outgoing; Thu, 20 Aug 2009 14:32:45 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] 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 n7KCWisJ002822 for ; Thu, 20 Aug 2009 14:32:44 +0200 (MEST)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id n7KCWcjB018095 for ; Thu, 20 Aug 2009 08:32:39 -0400
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Aug 2009 13:32:42 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [ietf-provreg] FW: Protocol Action: 'Extensible Provisioning Protocol (EPP) Transportover TCP' to Full Standard
Date: Thu, 20 Aug 2009 08:32:41 -0400
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Protocol Action: 'Extensible Provisioning Protocol (EPP) Transportover TCP' to Full Standard
Thread-Index: AcohCAe8oQdBj2flTFipMWRjhQNMaAAie7fA
From: "Hollenbeck, Scott"
To:
X-OriginalArrivalTime: 20 Aug 2009 12:32:42.0277 (UTC) FILETIME=[4FE41550:01CA2192]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n7KCWjsJ005151
Sender: [email-masked]
Precedence: bulk

4934bis has been approved by the IESG. That's the last of the document
updates for Full Standard. An updated implementation report can be
found here:

http://www.ietf.org/iesg/implementation/report-rfc4930-4934.txt

Thanks to everyone who helped move this forward.

-Scott-

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of The IESG
Sent: Wednesday, August 19, 2009 4:01 PM
To: IETF-Announce
Cc: Internet Architecture Board; RFC Editor
Subject: Protocol Action: 'Extensible Provisioning Protocol (EPP)
Transportover TCP' to Full Standard

The IESG has approved the following document:

- 'Extensible Provisioning Protocol (EPP) Transport over TCP '
as a Full Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Alexey Melnikov.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hollenbeck-rfc4934bis-01.txt

Technical Summary
This set of documents advances EPP to Standard. References
have been updated and non-normative text updates have been made.
Some clarifications on TLS server sertificate verification were done.

Working Group Summary
This is the product of an individual submitter, though the working
group mailing list of PROVREG (now closed) was used to review the
updates to the documents.

Document Quality
Issues raised by AD review were addressed.
There are multiple implementations of the protocol, as described in
the implementation report.

Personnel
Edward Lewis is the document shepherd for this series
(draft-hollenbeck-rfc493*bis) of documents.
Alexey Melnikov is the responsible Area Director.

RFC Editor note:

In Section 9, insert a new paragraph after the paragraph starting with
"If the server identity check fails". (The new paragraph would be 3rd to
the last):

During the TLS negotiation, the EPP server MUST verify that the client
certificate matches the reference identity previously negotiated out of
band, as specified in section 8. The server should match the entire
subject name or the subjectAltName as described in RFC 5280. The server
MAY enforce other restrictions on the subjectAltName, for example if it
knows that a particular client is always connecting from a particular
hostname/IP address.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n7JGMChc014565 for ; Wed, 19 Aug 2009 18:22:12 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n7JGMC3E013062 for ietf-provreg-outgoing; Wed, 19 Aug 2009 18:22:12 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from clone.registro.br (clone.registro.br [200.160.2.4]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n7JGMBHl005862 for ; Wed, 19 Aug 2009 18:22:12 +0200 (MEST)
Received: by clone.registro.br (Postfix, from userid 1000) id 2625B95873; Wed, 19 Aug 2009 13:22:10 -0300 (BRT)
Date: Wed, 19 Aug 2009 13:22:10 -0300
From: Frederico A C Neves
To: "Hollenbeck, Scott"
Cc: [email-masked]
Subject: Re: [ietf-provreg] EPP Server Implementer Help Needed
Message-ID: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
Sender: [email-masked]
Precedence: bulk

On Wed, Aug 19, 2009 at 11:28:36AM -0400, Hollenbeck, Scott wrote:
> Great - thanks! Can you tell me how you would want to see your server
> implementation identified in the implementation report?

Registro.br

> -Scott-

Fred
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n7JFScjW021269 for ; Wed, 19 Aug 2009 17:28:38 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n7JFSclO025446 for ietf-provreg-outgoing; Wed, 19 Aug 2009 17:28:38 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] 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 n7JFSbqT025979 for ; Wed, 19 Aug 2009 17:28:37 +0200 (MEST)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id n7JFSYp7011891; Wed, 19 Aug 2009 11:28:34 -0400
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 16:28:36 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [ietf-provreg] EPP Server Implementer Help Needed
Date: Wed, 19 Aug 2009 11:28:36 -0400
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-provreg] EPP Server Implementer Help Needed
Thread-Index: Acog4UbFGHxt3d/bSJSYyxFWsin2GQAAFT3Q
References: <[email-masked]> <[email-masked]>
From: "Hollenbeck, Scott"
To: "Frederico A C Neves" ,
X-OriginalArrivalTime: 19 Aug 2009 15:28:36.0035 (UTC) FILETIME=[B8020130:01CA20E1]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n7JFSbqT009093
Sender: [email-masked]
Precedence: bulk

Great - thanks! Can you tell me how you would want to see your server
implementation identified in the implementation report?

-Scott-

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Frederico A C Neves
> Sent: Wednesday, August 19, 2009 10:59 AM
> To: [email-masked]
> Subject: Re: [ietf-provreg] EPP Server Implementer Help Needed
>
> Scott,
>
> On Tue, Aug 18, 2009 at 07:16:48AM -0400, Hollenbeck, Scott wrote:
> > I still need info from one server implementer that is willing to be
> > included in an implementation report and confirm that they have
> > implemented the TLS client identification features described in
> > section
> > 9 of 4934bis. Specifically:
> >
> > 1. TLS implementations are REQUIRED to support the mandatory cipher
> > suite specified in the implemented version:
> >
> > 2. Mutual client and server authentication using the TLS Handshake
> > Protocol is REQUIRED.
> >
> > 3. Signatures on the complete certification path for both client
> > machine and server machine MUST be validated as part of the
> TLS handshake.
> >
> > 4. Information included in the client and server
> certificates, such as
> > validity periods and machine names, MUST also be validated.
> >
> > 5. EPP service MUST NOT be granted until successful completion of a
> > TLS handshake and certificate validation
> >
> > Most of these come for free with a good TLS toolkit. Are there any
> > server implementers willing to confirm that they've
> implemented these
> > features? I've already confirmed that VeriSign has
> implemented these
> > features.
>
> I could confirm that our server does implement all these features.
>
> On the client side I could confirm several production
> clients. Some using our own client, private implementations
> and at least two client using Verising NameStore and Key-Systems.
>
> Our own client software does almost all checks except the
> validation of the server name and the CN on the server
> certificate. Next release will include this small patch.
>
> > -Scott-
>
> Fred
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> -=-=-=-=-=-=-
> List run by majordomo software. For (Un-)subscription and
> similar details send "help" to [email-masked]
>
>

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n7JEx8FP006262 for ; Wed, 19 Aug 2009 16:59:08 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n7JEx8al027617 for ietf-provreg-outgoing; Wed, 19 Aug 2009 16:59:08 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from clone.registro.br (clone.registro.br [200.160.2.4]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n7JEx7H3011273 for ; Wed, 19 Aug 2009 16:59:08 +0200 (MEST)
Received: by clone.registro.br (Postfix, from userid 1000) id D2FED9584E; Wed, 19 Aug 2009 11:59:05 -0300 (BRT)
Date: Wed, 19 Aug 2009 11:59:05 -0300
From: Frederico A C Neves
To: [email-masked]
Subject: Re: [ietf-provreg] EPP Server Implementer Help Needed
Message-ID: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
Sender: [email-masked]
Precedence: bulk

Scott,

On Tue, Aug 18, 2009 at 07:16:48AM -0400, Hollenbeck, Scott wrote:
> I still need info from one server implementer that is willing to be
> included in an implementation report and confirm that they have
> implemented the TLS client identification features described in section
> 9 of 4934bis. Specifically:
>
> 1. TLS implementations are REQUIRED to support the mandatory cipher
> suite specified in the implemented version:
>
> 2. Mutual client and server authentication using the TLS Handshake
> Protocol is REQUIRED.
>
> 3. Signatures on the complete certification path for both client machine
> and server machine MUST be validated as part of the TLS handshake.
>
> 4. Information included in the client and server certificates, such as
> validity periods and machine names, MUST also be validated.
>
> 5. EPP service MUST NOT be granted until successful completion of a TLS
> handshake and certificate validation
>
> Most of these come for free with a good TLS toolkit. Are there any
> server implementers willing to confirm that they've implemented these
> features? I've already confirmed that VeriSign has implemented these
> features.

I could confirm that our server does implement all these features.

On the client side I could confirm several production clients. Some
using our own client, private implementations and at least two client
using Verising NameStore and Key-Systems.

Our own client software does almost all checks except the validation
of the server name and the CN on the server certificate. Next release
will include this small patch.

> -Scott-

Fred
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n7IGjk1f009472 for ; Tue, 18 Aug 2009 18:45:46 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n7IGjk4W014498 for ietf-provreg-outgoing; Tue, 18 Aug 2009 18:45:46 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] 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 n7IGjjWf023512 for ; Tue, 18 Aug 2009 18:45:45 +0200 (MEST)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id n7IGjhZx032710; Tue, 18 Aug 2009 12:45:43 -0400
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 17:45:44 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [ietf-provreg] EPP Server Implementer Help Needed
Date: Tue, 18 Aug 2009 12:45:43 -0400
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-provreg] EPP Server Implementer Help Needed
Thread-Index: AcogHNF4dzT1s3DMSNafSpUgoU0pMwABihGA
References: <[email-masked]> <[email-masked]>
From: "Hollenbeck, Scott"
To: "Francisco Obispo"
Cc:
X-OriginalArrivalTime: 18 Aug 2009 16:45:44.0213 (UTC) FILETIME=[54342C50:01CA2023]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n7IGjjWf016491
Sender: [email-masked]
Precedence: bulk

TLS was selected because it was thought to provide the best fit for the requirements identified in RFC 3375.

-Scott-

> -----Original Message-----
> From: Francisco Obispo [mailto:[email-masked]]
> Sent: Tuesday, August 18, 2009 11:59 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> Subject: Re: [ietf-provreg] EPP Server Implementer Help Needed
>
> Hi Scott,
>
> Although this comment might seem odd, I was wondering, why
> the TLS feature is required.
>
> When I was in charge of .VE we decided not to include any
> encryption/ auth features besides regular user/pass simple auth.
>
> Later on, we decided to use SSL/TLS tunneling with a
> sepparate software package, that will provide the encryption
> services. At first we used ssh, but stunnel turned out to be
> a better solution.
> if we were to require stronger encryption, we could start by
> introducing other software packages, but taking the
> complications outside of the EPP implementation...
>
> I don´t know if using third party software will comply with
> this requirement, because if it does, then it might be a good
> idea to switch to that instead.
>
> Regards
>
> Francisco
>
>
>
> On Aug 18, 2009, at 6:46 AM, Hollenbeck, Scott wrote:
>
> > I still need info from one server implementer that is willing to be
> > included in an implementation report and confirm that they have
> > implemented the TLS client identification features described in
> > section
> > 9 of 4934bis. Specifically:
> >
> > 1. TLS implementations are REQUIRED to support the mandatory cipher
> > suite specified in the implemented version:
> >
> > 2. Mutual client and server authentication using the TLS Handshake
> > Protocol is REQUIRED.
> >
> > 3. Signatures on the complete certification path for both client
> > machine and server machine MUST be validated as part of the TLS
> > handshake.
> >
> > 4. Information included in the client and server
> certificates, such as
> > validity periods and machine names, MUST also be validated.
> >
> > 5. EPP service MUST NOT be granted until successful completion of a
> > TLS handshake and certificate validation
> >
> > Most of these come for free with a good TLS toolkit. Are there any
> > server implementers willing to confirm that they've
> implemented these
> > features? I've already confirmed that VeriSign has
> implemented these
> > features.
> >
> > -Scott-
> >
> >
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > =-=-=-
> > List run by majordomo software. For (Un-)subscription and similar
> > details send "help" to [email-masked]
> >
> >
>
>

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n7IFx6Rx006163 for ; Tue, 18 Aug 2009 17:59:06 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n7IFx6VN012314 for ietf-provreg-outgoing; Tue, 18 Aug 2009 17:59:06 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from smtp.cenit.gob.ve (smtp.cenit.gob.ve [150.188.4.71]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n7IFx5ai014491 for ; Tue, 18 Aug 2009 17:59:06 +0200 (MEST)
Received: from [150.186.201.2] (unknown [150.186.201.2]) by smtp.cenit.gob.ve (Postfix) with ESMTP id 1F2073ED4; Tue, 18 Aug 2009 11:34:37 -0430 (VET)
Cc:
Message-Id: <[email-masked]>
From: Francisco Obispo
To: "Hollenbeck, Scott"
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: [ietf-provreg] EPP Server Implementer Help Needed
Date: Tue, 18 Aug 2009 11:29:03 -0430
References: <[email-masked]>
X-Mailer: Apple Mail (2.935.3)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n7IFx6ai012980
Sender: [email-masked]
Precedence: bulk

Hi Scott,

Although this comment might seem odd, I was wondering, why the TLS
feature is required.

When I was in charge of .VE we decided not to include any encryption/
auth features besides regular user/pass simple auth.

Later on, we decided to use SSL/TLS tunneling with a sepparate
software package, that will provide the encryption services. At first
we used ssh, but stunnel turned out to be a better solution.
if we were to require stronger encryption, we could start by
introducing other software packages, but taking the complications
outside of the EPP implementation...

I don´t know if using third party software will comply with this
requirement, because if it does, then it might be a good idea to
switch to that instead.

Regards

Francisco

On Aug 18, 2009, at 6:46 AM, Hollenbeck, Scott wrote:

> I still need info from one server implementer that is willing to be
> included in an implementation report and confirm that they have
> implemented the TLS client identification features described in
> section
> 9 of 4934bis. Specifically:
>
> 1. TLS implementations are REQUIRED to support the mandatory cipher
> suite specified in the implemented version:
>
> 2. Mutual client and server authentication using the TLS Handshake
> Protocol is REQUIRED.
>
> 3. Signatures on the complete certification path for both client
> machine
> and server machine MUST be validated as part of the TLS handshake.
>
> 4. Information included in the client and server certificates, such as
> validity periods and machine names, MUST also be validated.
>
> 5. EPP service MUST NOT be granted until successful completion of a
> TLS
> handshake and certificate validation
>
> Most of these come for free with a good TLS toolkit. Are there any
> server implementers willing to confirm that they've implemented these
> features? I've already confirmed that VeriSign has implemented these
> features.
>
> -Scott-
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> =-=-=-
> List run by majordomo software. For (Un-)subscription and similar
> details
> send "help" to [email-masked]
>
>

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n7IBGoBJ007524 for ; Tue, 18 Aug 2009 13:16:50 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n7IBGo51011656 for ietf-provreg-outgoing; Tue, 18 Aug 2009 13:16:50 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n7IBGn8h011831 for ; Tue, 18 Aug 2009 13:16:50 +0200 (MEST)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id n7IB3Q9h005239 for ; Tue, 18 Aug 2009 07:03:26 -0400
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 12:16:48 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [ietf-provreg] EPP Server Implementer Help Needed
Date: Tue, 18 Aug 2009 07:16:48 -0400
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: EPP Server Implementer Help Needed
Thread-Index: Acof9WCQ6p4pq/w8S7i3z62KD+oq+Q==
From: "Hollenbeck, Scott"
To:
X-OriginalArrivalTime: 18 Aug 2009 11:16:48.0563 (UTC) FILETIME=[60D6F830:01CA1FF5]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n7IBGo8h016055
Sender: [email-masked]
Precedence: bulk

I still need info from one server implementer that is willing to be
included in an implementation report and confirm that they have
implemented the TLS client identification features described in section
9 of 4934bis. Specifically:

1. TLS implementations are REQUIRED to support the mandatory cipher
suite specified in the implemented version:

2. Mutual client and server authentication using the TLS Handshake
Protocol is REQUIRED.

3. Signatures on the complete certification path for both client machine
and server machine MUST be validated as part of the TLS handshake.

4. Information included in the client and server certificates, such as
validity periods and machine names, MUST also be validated.

5. EPP service MUST NOT be granted until successful completion of a TLS
handshake and certificate validation

Most of these come for free with a good TLS toolkit. Are there any
server implementers willing to confirm that they've implemented these
features? I've already confirmed that VeriSign has implemented these
features.

-Scott-

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]