Re: [Uta] UTA: Server certificate management (Re: Last Call: <draft-ietf-uta-email-tls-certs-05.txt>)
Alexey Melnikov <alexey.melnikov@isode.com> Wed, 02 December 2015 12:29 UTC
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9587A1A8953; Wed, 2 Dec 2015 04:29:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyJ0JyKltOSg; Wed, 2 Dec 2015 04:29:31 -0800 (PST)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id DBDF01A8961; Wed, 2 Dec 2015 04:29:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1449059362; d=isode.com; s=selector; i=@isode.com; bh=TLiu0RQRxZezY/F19f6hnOgRPu7bIY/+6l51zdxW8bg=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=NzWmOVV/8kb3+h9cqEtjghTV6JAbqR+hWtIep1iRxmfad5L1i0P2LU82Zx1QLNBCfZreU9 i6y8/bO2khhCOmx+GCCaeFJzl5nklCGYgUkEGsUp/pw1YTvq02D4hCqgoHjHBBDmR1leLx nMr+Rqg/WtGUIBwq3zv3WCmIvoKA9jo=;
Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <Vl7kIQAlTgjf@statler.isode.com>; Wed, 2 Dec 2015 12:29:21 +0000
Message-ID: <565EE412.6040106@isode.com>
Date: Wed, 02 Dec 2015 12:29:06 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
To: Harald Alvestrand <harald@alvestrand.no>, ietf@ietf.org
References: <20151120142925.18541.72151.idtracker@ietfa.amsl.com> <565DAFF8.10603@alvestrand.no>
In-Reply-To: <565DAFF8.10603@alvestrand.no>
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/AmYS8sECMKClHJ9yeHtvx17LaoE>
Cc: uta@ietf.org, uta-chairs@ietf.org, draft-ietf-uta-email-tls-certs@ietf.org, leifj@sunet.se
Subject: Re: [Uta] UTA: Server certificate management (Re: Last Call: <draft-ietf-uta-email-tls-certs-05.txt>)
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Dec 2015 12:29:32 -0000
Hi Harald, On 01/12/2015 14:34, Harald Alvestrand wrote: > If I understand this draft correctly, I object. > > It says: > > > 2. When using email service discovery procedure specified in > [RFC6186] the client MUST also use the right hand side of the > email address as another "reference identifier" to compare > against SRV-ID identifier in the server certificate. > > > If I understand RFC 6186 correctly, a (possibly large scale) IMAP email > service provider that wishes to serve a new domain "example org" > according to RFC 6186 must do two things: > > - Update internal tables of its servers with inforamation about that domain. > - Populate the DNS of the domain served with an _imap record. > > If I understand this draft correctly, the server will have to do one > more thing: > > - Change its certificate to include a complete list of all the domains > it is serving, and have its CA sign off on that certificate. Yes, or alternatively, one can do one of two other things: 1) use Server Name Indication TLS extension. At the moment none of the email specs requires it. But maybe it is something that the draft should encourage. 2) run each domain on its own IP/port, then each IP/port can use separate certificate with a single domain. As Dave Cridland pointed out, POSH (RFC 7711) is trying to solve the problem of hosting multiple domains, but its use is not defined for email yet. I think it is out of scope for this document. > The reason it cannot provide one certificate per served domain is that > neither this specification nor any other specification I have found says > that the client MUST include any distinguishing information (such as a > Server Name Indication) that says what name it is expecting the server > to provide service for. That is correct, see above. > Given the popularity of multi-domain mail servers (my own tiny little > mail servers has 9 domains it calls its own, some of which I do not wish > to advertise), I see this as a problem. > > If I have misunderstood the issue, I apologize. Best Regards, Alexey
- [Uta] Last Call: <draft-ietf-uta-email-tls-certs-… The IESG
- Re: [Uta] Last Call: <draft-ietf-uta-email-tls-ce… Russ Housley
- Re: [Uta] Last Call: <draft-ietf-uta-email-tls-ce… Alexey Melnikov
- Re: [Uta] Last Call: <draft-ietf-uta-email-tls-ce… Leif Johansson
- Re: [Uta] Last Call: <draft-ietf-uta-email-tls-ce… Russ Housley
- Re: [Uta] Last Call: <draft-ietf-uta-email-tls-ce… Viktor Dukhovni
- Re: [Uta] Last Call: <draft-ietf-uta-email-tls-ce… Viktor Dukhovni
- Re: [Uta] Last Call: <draft-ietf-uta-email-tls-ce… stephen.farrell
- Re: [Uta] Last Call: <draft-ietf-uta-email-tls-ce… Alexey Melnikov
- Re: [Uta] Last Call: <draft-ietf-uta-email-tls-ce… Julien ÉLIE
- Re: [Uta] Last Call: <draft-ietf-uta-email-tls-ce… Alexey Melnikov
- Re: [Uta] Last Call: <draft-ietf-uta-email-tls-ce… Leif Johansson
- Re: [Uta] UTA: Server certificate management (Re:… Viktor Dukhovni
- Re: [Uta] UTA: Server certificate management (Re:… John Levine
- Re: [Uta] UTA: Server certificate management (Re:… Viktor Dukhovni
- Re: [Uta] UTA: Server certificate management (Re:… John Levine
- Re: [Uta] UTA: Server certificate management (Re:… Alexey Melnikov
- Re: [Uta] UTA: Server certificate management (Re:… Alexey Melnikov
- Re: [Uta] UTA: Server certificate management (Re:… John R Levine
- Re: [Uta] UTA: Server certificate management (Re:… Alexey Melnikov
- Re: [Uta] UTA: Server certificate management (Re:… John Levine
- Re: [Uta] UTA: Server certificate management (Re:… Alexey Melnikov
- Re: [Uta] UTA: Server certificate management (Re:… John R Levine
- Re: [Uta] UTA: Server certificate management (Re:… Alexey Melnikov
- Re: [Uta] UTA: Server certificate management (Re:… John R Levine
- Re: [Uta] UTA: Server certificate management (Re:… Alexey Melnikov