[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: ietf-provreg@cafax.se
From: Patrick Mevzek <provreg@contact.dotandco.com>
Date: Tue, 14 Apr 2009 15:23:30 +0200
Content-Disposition: inline
In-Reply-To: <046F43A8D79C794FA4733814869CDF07029FD625@dul1wnexmb01.vcorp.ad.vrsn.com>
Sender: owner-ietf-provreg@cafax.se
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [ietf-provreg] AD Review Comments:draft-hollenbeck-rfc4934bis-00

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/>

Home | Date list | Subject list