On 11/18/19 3:42 PM, Alan DeKok wrote:
On Nov 18, 2019, at 6:22 PM, Dan Harkins wrote:
On 11/12/19 3:40 PM, Alan DeKok wrote:
On Nov 12, 2019, at 3:13 PM, Cappalli, Tim (Aruba) wrote:
How does a public CA prove ownership of an SSID?
Do public CAs *always* verify addresses and/or
Hi Alan,
On 11/12/19 3:40 PM, Alan DeKok wrote:
On Nov 12, 2019, at 3:13 PM, Cappalli, Tim (Aruba) 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
On Nov 18, 2019, at 11:01 AM, Cappalli, Tim (Aruba) wrote:
>
> So you’re saying an NAIRealm must be a publicly registered domain name? I
> agree, but just want to be crystal clear.
Yes. See RFC 7542. It defines the NAI in some detail.
Alan DeKok.
So you’re saying an NAIRealm must be a publicly registered domain name? I
agree, but just want to be crystal clear.
tim
From: Alan DeKok
Date: Monday, November 18, 2019 at 10:57 AM
To: Cappalli, Tim (Aruba)
Cc: EMU WG
Subject: Re: [Emu] Best practices for supplicants and authenticators
>
Alan – Adding yet another OID and/or EKU to a certificate does not change the
fact that no authority can attest to that information. A public CA cannot
validate a ownership of an NAIRealm. So while a supplicant could be configured
to validate that the server’s NAIRealm matches the local
On Nov 18, 2019, at 10:37 AM, Cappalli, Tim (Aruba) wrote:
>
> If the goal is not to improve identity assurance of an EAP server then what
> is this best practice change actually for?
I have been *explicit* in my statements that my goal *is* to improve
validation of the EAP server identity.
If the goal is not to improve identity assurance of an EAP server then what is
this best practice change actually for?
From: Alan DeKok
Date: Monday, November 18, 2019 at 10:34 AM
To: Cappalli, Tim (Aruba)
Cc: EMU WG
Subject: Re: [Emu] Best practices for supplicants and authenticators
>
> On Nov 18, 2019, at 10:22 AM, Cappalli, Tim (Aruba) wrote:
>
> So again, if NAIRealm is not bound to an organization’s public domain name,
I never suggested that or implied it. I'm not sure why it's relevant.
> how does a public CA prove ownership of an NAIRealm? How is this different
On 18.11.19 16:22, Cappalli, Tim (Aruba) wrote:
> So again, if NAIRealm is not bound to an organization’s public domain
> name, how does a public CA prove ownership of an NAIRealm? How is this
> different than ESSID?
It must not be a public domain name, but it can be.
Speaking of eduroam this is
So again, if NAIRealm is not bound to an organization’s public domain name, how
does a public CA prove ownership of an NAIRealm? How is this different than
ESSID?
I don’t see how this improves assurance of a server identity.
tim
From: Emu
Date: Monday, November 18, 2019 at 9:18 AM
To: EMU WG
Joseph Salowey has requested publication of draft-ietf-emu-rfc5448bis-06 as
Informational on behalf of the EMU working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-emu-rfc5448bis/
___
Emu mailing list
After the meeting earlier today, I made some notes on best practices for
supplicants and authenticators. I think it would be useful to have an official
WG document which gives guidance.
Background:
a) the current practice in TLS-based EAP methods is to use certificates with
12 matches
Mail list logo
