[pkix] FW: [cabfpub] "Authorized Port"
Ben Wilson <email@example.com> Fri, 04 September 2015 15:15 UTC
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8051B3ECC for <firstname.lastname@example.org>; Fri, 4 Sep 2015 08:15:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-1.512 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([220.127.116.11]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeRkwcTnvwFH for <email@example.com>; Fri, 4 Sep 2015 08:15:17 -0700 (PDT)
Received: from mail.digicert.com (mail.digicert.com [18.104.22.168]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ADBA1B3F1E for <firstname.lastname@example.org>; Fri, 4 Sep 2015 08:15:14 -0700 (PDT)
From: Ben Wilson <email@example.com>
To: "firstname.lastname@example.org" <email@example.com>
Thread-Topic: [cabfpub] "Authorized Port"
Date: Fri, 4 Sep 2015 15:15:11 +0000
References: <35eec2f189bd4a89a4b16ce46a378ddc@EX2.corp.digicert.com> <55E95788.firstname.lastname@example.org> <2e76c8bbafe641acaefa036d17c5ea75@EX2.corp.digicert.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001B_01D0E6F2.332262B0"
Subject: [pkix] FW: [cabfpub] "Authorized Port"
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Sep 2015 15:15:19 -0000
Forwarding to this list for additional input. -----Original Message----- From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Ben Wilson Sent: Friday, September 4, 2015 9:03 AM To: Gervase Markham <email@example.com>rg>; Ryan Sleevi (firstname.lastname@example.org) <email@example.com>om>; CABFPub <firstname.lastname@example.org> Subject: Re: [cabfpub] "Authorized Port" This is good discussion. Let's keep it up. We need more people to chime in. -----Original Message----- From: Gervase Markham [mailto:email@example.com] Sent: Friday, September 4, 2015 2:34 AM To: Ben Wilson <firstname.lastname@example.org>om>; CABFPub <email@example.com> Subject: Re: [cabfpub] "Authorized Port" >On 03/09/15 18:06, Ben Wilson wrote: >> The Validation Working Group is considering amendments to the domain >> validation processes. Two of those processes use the concept of an >> “authorized port” in order to limit the threat of approvals occurring >> through ports that are not “well-known”. > Why would one want to permit approvals for an SSL certificate through a port > which was well-known for not being SSL? > Is this because of STARTTLS and equivalents? > I also agree with Ryan that control of any port over 1024 should not be considered to > be the same as control of the server or the FQDN which points to it. > Gerv >>> All, >>> The Validation Working Group is considering amendments to the domain validation processes. >>> Two of those processes use the concept of an “authorized port” in order to limit the threat of >>> approvals occurring through ports that are not “well-known”. >>> Here is the relevant language of the draft ballot: >>> >>> 6. Having the Applicant demonstrate control over the requested FQDN by installing a Random Value >>> (contained in the name of the file, the content of a file, on a web page in the form of a meta tag, or >>> any other format as determined by the CA) under "/.well-known/validation" directory on an Authorized >>> Domain Name that can be validated over an Authorized Port; >>> … >>> 9. Having the Applicant demonstrate control over the FQDN by the Applicant requesting and then >>> installing a Test Certificate issued by the CA on the FQDN which is accessed and then validated via >>> https by the CA over an Authorized Port; >>> I have argued in support of at least the following ports: >>> Authorized Ports Not SSL/TLS SSL/TLS >>> ftp 20-21 989-990 >>> ssh 22 >>> telnet 23 992 >>> smtp 25, 587 465 >>> http 80 443 >>> pop 110 995 >>> nntp 119 563 >>> imap 143 993 >>> irc 194 994 >>> ldap 389 636 >>> sip 5060 5061 >>> Sample of ports that wouldn't be included (among 1,000s of others) >>> sftp 115 >>> active-directory 445 >>> rfs 556 >>> filemaker 591 >>> rpc-over-http 593 >>> ieee-mms-ssl 695 >>> kerberos 749-752 >>> brocade-ssl 898 >>> vmware 901-904 >>> ibm 1364 >>> c-panel 2083 >>> In a written list I included port 24 (private mail) and 991 (network news) because >>> they were consecutive within a series below for the definition of “Authorized Port”– >>> >>> “ “Authorized Port” means ports 20-25, 80, 110, 119, 143, 194, 389, 443, 465, >>> 563, 587, 636, 989-995.” >>> I’ve told the Validation Working Group that I think we need to reach outside >>> the Validation WG to confirm whether this limited list is of the right scope. >>> If you have any opinions, please respond. >>> Thanks, >>> Ben
- [pkix] FW: [cabfpub] "Authorized Port" Ben Wilson