IETF Logo Mail Archive

Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

Dan Harkins <dharkins@lounge.org> Mon, 18 November 2019 23:22 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA020120A3D for <emu@ietfa.amsl.com>; Mon, 18 Nov 2019 15:22:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 DYhhNDNZgLcC for <emu@ietfa.amsl.com>; Mon, 18 Nov 2019 15:22:25 -0800 (PST)
Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689F1120919 for <emu@ietf.org>; Mon, 18 Nov 2019 15:22:25 -0800 (PST)
Received: from trixy.bergandi.net (cpe-76-93-158-174.san.res.rr.com [76.93.158.174]) by wwwlocal.goatley.com (PMDF V6.8-0 #1001) with ESMTP id <0Q1600DAUU9CKN@wwwlocal.goatley.com> for emu@ietf.org; Mon, 18 Nov 2019 17:22:24 -0600 (CST)
Received: from Dans-MacBook-Pro.local ([101.100.166.3]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0Q1600ODTU4WOZ@trixy.bergandi.net> for emu@ietf.org; Mon, 18 Nov 2019 15:19:45 -0800 (PST)
Received: from 3-166-100-101.myrepublic.com.sg ([101.100.166.3] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Mon, 18 Nov 2019 15:19:45 -0800
Date: Mon, 18 Nov 2019 15:22:21 -0800
From: Dan Harkins <dharkins@lounge.org>
In-reply-to: <9907D136-C262-48BC-8630-0EABC0EB97F5@deployingradius.com>
To: emu@ietf.org
Message-id: <c54e1c65-8600-9b36-5b97-7c1425a82fc3@lounge.org>
MIME-version: 1.0
Content-type: text/plain; charset="utf-8"; format="flowed"
Content-language: en-US
Content-transfer-encoding: 8bit
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=101.100.166.3)
X-PMAS-External-Auth: 3-166-100-101.myrepublic.com.sg [101.100.166.3] (EHLO Dans-MacBook-Pro.local)
References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <D735A4DB-1CFB-4DF4-ACB7-BC6EFDBC6CDE@deployingradius.com> <E0B8DAA7-8C7C-455F-B5BE-128670A093D3@vigilsec.com> <BD30A64D-539C-422D-9413-880AF8D6A16F@deployingradius.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <MN2PR11MB3901077F38165EE241D30BC5DB740@MN2PR11MB3901.namprd11.prod.outlook.com> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <46C8D8C4-7317-47F3-8F9B-6C56F7B7FEE9@vigilsec.com> <F45360DB-D474-4600-BEFD-3C844FA4CB0A@deployingradius.com> <AT5PR8401MB05309002D11E8AEF1018D250DB770@AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM> <9907D136-C262-48BC-8630-0EABC0EB97F5@deployingradius.com>
X-PMAS-Software: PreciseMail V3.3 [191118] (trixy.bergandi.net)
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/za1OYoXb0s4lGOuQ-sLVkMZUMsc>
Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Nov 2019 23:22:30 -0000

   Hi Alan,

On 11/12/19 3:40 PM, Alan DeKok wrote:
> On Nov 12, 2019, at 3:13 PM, Cappalli, Tim (Aruba) <timc@hpe.com> wrote:
>> How does a public CA prove ownership of an SSID?
>    Do public CAs *always* verify addresses and/or telephone numbers, which are normally included in certificates?
>
>    Do public CAs verify that email addresses in the certificate work?
>
>    Do public CAs verify that the OIDs in the certificate match the intended use-cases?
>
>    Is there a global registry of SSIDs which the public CA could use to verify the SSID?

   I'm taking these as rhetorical questions with an implied "no". If that is
not the correct way of taking them then please let me know.

   So the issue is, if the CA does not check any of these things then 
you cannot
trust them in the certificate. The reason you trust the contents of a 
certificate
is because you trust the CA has done the appropriate due diligence to 
validate
the stuff it is certifying. If a CA doesn't do the due diligence on any 
of the
above stuff and still issues a certificate containing that stuff then I 
would
question the integrity of the CA and probably not trust other things it is
certifying. In other words, I'd probably remove that CA's cert from my TADB.

>    To put it another way, I'm not sure why this question is being posed.

   Here's one: Why would you trust an attribute that was not validated?

   Dan.

>
>    Alan DeKok.
>
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu

v2.23.0 | Report a Bug | By Email