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

Patrick Mevzek <provreg@contact.dotandco.com> Tue, 14 April 2009 13:39 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 61D6B3A6AD0 for <ietfarch-provreg-archive@core3.amsl.com>; Tue, 14 Apr 2009 06:39:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 5S6GlvcwFMj9 for <ietfarch-provreg-archive@core3.amsl.com>; Tue, 14 Apr 2009 06:39:51 -0700 (PDT)
Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 10AC63A6A9E for <provreg-archive@ietf.org>; Tue, 14 Apr 2009 06:39:50 -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 n3EDNVeS020492 for <ietf-provreg-outgoing@nic.cafax.se>; Tue, 14 Apr 2009 15:23:31 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n3EDNVlh011240 for ietf-provreg-outgoing; Tue, 14 Apr 2009 15:23:31 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se 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 n3EDNViX007609 for <ietf-provreg@cafax.se>; Tue, 14 Apr 2009 15:23:31 +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 n3EDNVx7014011; Tue, 14 Apr 2009 15:23:31 +0200
Received: from localhost (localhost [[UNIX: localhost]]) by triglav.dotandco.com (8.13.8/8.13.8/Submit) id n3EDNUFh014010; Tue, 14 Apr 2009 15:23:30 +0200
X-Authentication-Warning: triglav.dotandco.com: patrick set sender to provreg@contact.dotandco.com using -f
Date: Tue, 14 Apr 2009 15:23:30 +0200
From: Patrick Mevzek <provreg@contact.dotandco.com>
To: ietf-provreg@cafax.se
Subject: Re: [ietf-provreg] AD Review Comments: draft-hollenbeck-rfc4934bis-00
Message-ID: <20090414132330.GB6802@home.patoche.org>
References: <046F43A8D79C794FA4733814869CDF07029FD625@dul1wnexmb01.vcorp.ad.vrsn.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <046F43A8D79C794FA4733814869CDF07029FD625@dul1wnexmb01.vcorp.ad.vrsn.com>
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]); Tue, 14 Apr 2009 15:23:31 +0200 (CEST)
Sender: owner-ietf-provreg@cafax.se
Precedence: bulk

Hollenbeck, Scott <shollenbeck@verisign.com> 2009-04-13 15:00
> > 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.

I may be totally blunt, but as I said before there is nothing in the
EPP use of TLS that is specific of EPP, it is just basic
client/server communication.
Some registries are not using TLS at all, specifically on test
servers.
Some registries do use TLS without mandating a specific client
certificate/certification path (that is autogenerated certificates are
accepted).
And I doubt that all clients check the server certificate credentials
(which are not necessarily changed often).
So the specifications should not put too much things on these points.

I may be silly but in my mind few MUST in RFC4934 related to
TLS authentication could be only SHOULD (in section 8), and the whole
part trimmed to say something along the line of 'standard TLS
shortcomings/best practices apply'

In all cases, I agree with the fact that this whole discussion has
nothing to do with EPP interoperability. In that sense, TLS is really
the last worry.

-- 
Patrick Mevzek
Dot and Co <http://www.dotandco.com/> <http://www.dotandco.net/>