On Mon, Jan 20, 2020 at 12:22 PM Michael Richardson
wrote:
>
> Alan DeKok wrote:
> > While, there are commercial supplicant products, these products are
> > overwhelmingly used by the enterprise, on computers owned by the
> > enterprise, and managed by the enterprise systems. They h
On Mon, Jan 20, 2020 at 3:31 PM Alan DeKok
wrote:
> > Is Cisco a supplicant vendor? Is Jouni Malinen a supplicant vendor? You
> have paths forward.
>
> Cisco: yes. Jouni: No.
>
> wpa_supplicant / hostap is just a collection of source code in a git
> tree. It includes no CAs. And if it did,
On Jan 20, 2020, at 11:51 AM, Ryan Sleevi wrote:
> On Mon, Jan 20, 2020 at 11:19 AM Alan DeKok wrote:
> The distinction doesn't even matter in the content of root stores. The
> vendor downloads N root CAs, and places them into files / DBs in the product.
> Whether those files from from A an
On Mon, Jan 20, 2020 at 12:28 PM David B. Nelson
wrote:
> On Jan 20, 2020, at 11:51 AM, Ryan Sleevi wrote:
>
>
> Whether we have to convince "the OS vendor", or just "the supplicant
>> division in the OS vendor" is largely the same thing.
>
>
> It isn’t, and there’s been zero evidence to suppo
On Jan 20, 2020, at 11:51 AM, Ryan Sleevi wrote:
>
> Whether we have to convince "the OS vendor", or just "the supplicant
> division in the OS vendor" is largely the same thing.
>
> It isn’t, and there’s been zero evidence to support that conclusion, but I
> can tell reality isn’t that convi
Alan DeKok wrote:
> While, there are commercial supplicant products, these products are
> overwhelmingly used by the enterprise, on computers owned by the
> enterprise, and managed by the enterprise systems. They have zero
> impact on the average user.
Today.
But, since a goal h
On Mon, Jan 20, 2020 at 11:19 AM Alan DeKok
wrote:
> The distinction doesn't even matter in the content of root stores. The
> vendor downloads N root CAs, and places them into files / DBs in the
> product. Whether those files from from A and go to B, or come from C and
> go to D is *entirely*
On Jan 20, 2020, at 10:44 AM, Ryan Sleevi wrote:
> It’s a distinction that cuts to the heart of the original proposal, echo’d
> several times on this thread: Can’t we just use the TLS CAs shipped by the OS
> today for this, ideally so that OS vendors don’t have any added work.
There has been
On Jan 20, 2020, at 11:19 AM, Alan DeKok wrote:
>
> Any "supplicant division" of an OS vendor will require high-level signify
> before massively changing user workflow. So in the end, it *is* the "OS
> vendor" who has to be convinced.
Please read "sign-off", not "signify". :(
Alan DeKok
On Jan 20, 2020, at 9:29 AM, Ryan Sleevi wrote:
> As I hoped my previous message conveyed, but it looks like it may not have
> been clear for you, I'm not dismissive that for supplicants distributed by
> the OS vendor, you (eventually) need to convince that OS vendor to distribute
> roots with
On Mon, Jan 20, 2020 at 10:13 AM David B. Nelson
wrote:
> The arguments about the differentiated policies for use of certificates
> and trust of CAs is probably technically sound. I think the notion that
> supplicant components can ship with a separate root CA store from that used
> for the brow
On Jan 20, 2020, at 9:29 AM, Ryan Sleevi wrote:
>
> I'm well aware the end goal is that on a 'stock' install of your OS of
> choice, everything just works. I've outlined several times a plan to get to
> that - and which does not involve shipping roots in the OS, but roots in the
> supplicant t
On Mon, Jan 20, 2020 at 8:53 AM Alan DeKok
wrote:
> I fully understand that applications can easily ship root CAs. We can
> therefore agree that the root CAs MUST be distributed with the software.
>
> But, precisely *zero* end users download their supplicant software. The
> supplicant softw
On Jan 19, 2020, at 12:12 PM, Ryan Sleevi wrote:
>
> > What matters is that the product the user ends up with has the CAs
> > preconfigured for EAP. The internal corporate structure is (to me)
> > irrelevant.
>
> Don’t conflate technical requirements with corporate structure. You’re
> insis
On Sun, Jan 19, 2020 at 11:42 AM Alan DeKok
wrote:
> > Supplicant vendors - whether they are open-source or operating system -
> are taking on the work to manage and police that root store.
>
> They "are" doing this? I don't see that.
This was trying to describe the world in which the second
On Sun, Jan 19, 2020 at 8:26 AM Russ Housley wrote:
>
> It seems to me that RFC 4334 offers a way for an enterprise to assert that
> the certificate is intended to be used with a particular SSID. This seems
> better than a self-signed certificate with just a domain name.
>
> I understand that C
On Jan 19, 2020, at 10:54 AM, Ryan Sleevi wrote:
> There’s zero need to use any existing CAs.
I agree.
> Of course, the CAs are only going to do that if there are users: those who
> will buy or rely on those certificates. So you need to convince supplicants
> that a zero-touch world is worth
It seems to me that RFC 4334 offers a way for an enterprise to assert that the
certificate is intended to be used with a particular SSID. This seems better
than a self-signed certificate with just a domain name.
I understand that CA/B Forum does not allow these extensions and attributes,
but a
I think we’re in more agreement than disagreement here, but I think part of
your analysis missed the mark.
On Sun, Jan 19, 2020 at 10:07 AM Alan DeKok
wrote:
> The question here is *what* root store? It's easy for browsers to ship
> root stores. The WWW root stores are well known.
>
> What
On Jan 18, 2020, at 6:30 PM, Ryan Sleevi wrote:
> Great. Let’s focus on one problem at a time to make sure it’s easier to
> follow along. Earlier in the thread you seemed fixated on the first problem,
> so it’s unclear when/where/how shifted to the second.
Perhaps less "fixated" than "trying
On Sat, Jan 18, 2020 at 5:58 PM Alan DeKok
wrote:
> I'm trying to solve the problem of bootstrapping. I agree that various
> CAs have various rules. I agree that anyone can run their own private CA,
> and do whatever they want. I've been doing that, and recommending it, for
> ~20 years.
Gr
On Jan 18, 2020, at 4:11 PM, Ryan Sleevi wrote:
>
> You’re conflating several things, as well as seemingly shifting the goal
> posts here. Perhaps it’s just a poor expression of the problem, as you see
> it, in which case, it might help to be clearer.
I'm trying to solve the problem of boots
On Sat, Jan 18, 2020 at 2:23 PM Alan DeKok
wrote:
> > Where can I get a certificate with id-kp-eapOverLAN? Or where can I
> get a cert designed for use with STMP, XMPP, etc.?
> >
> > https://wiki.xmpp.org/web/XMPP_Server_Certificates
> >
> https://xmpp.org/about/xsf/records/proposals/intermedi
> There’s no set of entities blessed in some special power which only they can
> mint certificates
Thank you for injecting some much-needed humor into this thread. That's the
funniest f---ing thing I've read from you in a long time.
___
Emu mailing
On Jan 18, 2020, at 11:10 AM, Ryan Sleevi wrote:
> If the point was a singular CA seeming to violate their CP/CPS (that is,
> DigiCert), then yes, absolutely, you can go submit a CA problem report and
> the CA is obligated to respond in 24 hours with their analysis to your
> problem report.
On Sat, Jan 18, 2020 at 9:43 AM Alan DeKok
wrote:
> On Jan 18, 2020, at 8:55 AM, Ryan Sleevi wrote:
> > Um, no. I largely didn’t respond to Michael’s email because it missed
> the mark rather substantially,
>
> In what way?
Which CAs (plural) are you referring to? The CertSign example given
Hiya,
On 18/01/2020 15:14, Ryan Sleevi wrote:
> The only way you sort through those is to make sure the only two parties
> are you and the CA - aka defining a root store.
I disagree. PKI inherently has 3 parties involved. Ignoring
any one or two of them is what I think leads to the kind of
silli
On Sat, Jan 18, 2020 at 9:22 AM Stephen Farrell
wrote:
>
> Hiya,
>
> On 18/01/2020 13:55, Ryan Sleevi wrote:
> > No. The root store operators make the rules. Standards that align with
> > their needs are the standards they use and apply.
> >
> > Nothing you say or do has any impact without implem
On Jan 18, 2020, at 8:55 AM, Ryan Sleevi wrote:
> On Sat, Jan 18, 2020 at 8:05 AM Alan DeKok wrote:
> As noted by Michael, CAs are using certificates in a way that violates
> their own policy.
>
> Um, no. I largely didn’t respond to Michael’s email because it missed the
> mark rather substa
Hiya,
On 18/01/2020 13:55, Ryan Sleevi wrote:
> No. The root store operators make the rules. Standards that align with
> their needs are the standards they use and apply.
>
> Nothing you say or do has any impact without implementor, and if you go
> against the grain of where implementors are goi
On Jan 18, 2020, at 8:55 AM, Ryan Sleevi wrote:
>
> No. The root store operators make the rules. Standards that align with their
> needs are the standards they use and apply.
>
> Nothing you say or do has any impact without implementor, and if you go
> against the grain of where implementors a
On Sat, Jan 18, 2020 at 8:05 AM Alan DeKok
wrote:
> As noted by Michael, CAs are using certificates in a way that violates
> their own policy.
Um, no. I largely didn’t respond to Michael’s email because it missed the
mark rather substantially, and I suspect folks still haven’t actually read
t
On Jan 18, 2020, at 2:20 AM, Ryan Sleevi wrote:
>
> Or... just stop using those certs/roots already? We’ve already identified
> that there is absolutely zero reason to do so in the extant status quo,
> because it still requires manual configuration.
... for EAP. And only for EAP.
That co
Or... just stop using those certs/roots already? We’ve already identified
that there is absolutely zero reason to do so in the extant status quo,
because it still requires manual configuration. You get no benefits and
clearly downsides, so just... don’t do that? Any complaints about how that
existi
If the PKI community as a whole (vendors, standards bodies, consortia, CAs) has
managed to engineer a situation where, according to the strict letter of the
law, CAs would have no choice but to revoke operators identity certificates for
many of their services if Alan was actually mean and wrote
Ryan Sleevi wrote:
> While I think people are missing the forest for the tree, here's an
> example CP/CPS from a CA:
>
https://www.certsign.ro/media/document/ZytpRDNNUTFHR01Ra2MxVUx4REdQZz09/original/CPS%20OV%20SSL_v%201.10_April%202019.pdf
certsign.ro uses a Fortinet.com certificat
On Jan 17, 2020, at 12:33 PM, Ryan Sleevi wrote:
> Does your RADIUS endpoint support and use OCSP stapling and disable WiFi if
> the certificate is expired? No? Then it's a potential violation of this
> CP/CPS.
I'm not sure how a RADIUS server will disable WiFi. They are entirely
separa
On Jan 17, 2020, at 1:29 PM, Michael Richardson wrote:
> You omitted an important part of that output, which is the name of the CA,
> which I include below.
Sure.
> It could be that the CSP permits SMTP, or SUBMISSION service.
> Ryan has suggested that CAs could put EAP-TLS (or EAP-TEAP) into
Alan DeKok wrote:
> Perhaps we should try?
> $ openssl s_client -connect smtp.mozilla.org:587 -starttls smtp >
mozilla.crt
> $ openssl x509 -text -in mozilla.crt
You omitted an important part of that output, which is the name of the CA,
which I include below.
It could be that the C
On Wed, Jan 15, 2020 at 11:07 PM Benjamin Kaduk wrote:
> A couple things that stand out to me from having basically read the whole
> thread in one go (this is not intended to be an exhaustive list of open
> questions):
>
> It was implied but not fully clear to me, that Ryan thinks that someone so
On 1/16/20 6:07 AM, Benjamin Kaduk wrote:
> Is there anything better for implementations to actually do (as distinct
> from what we write down as recommendations) than to start setting up a
> parallel (purpose-specific) PKI now and trusting that in parallel with what
> they're currently doing, with
On Jan 16, 2020, at 4:02 PM, Eliot Lear (elear) wrote:
>
> Ok not for nothing but this is getting silly.
Yes.
> If a CA actually revoked a cert for someone using it for EAP, would they
> also have to revoke for someone using it for SMTP, XMPP, and IMAP?
That is apparently the claim.
>
On 8 Jan 2020, at 17:29, Ryan Sleevi
mailto:ryan-i...@sleevi.com>> wrote:
The CA must revoke if the certificate is misused; that's required by contract.
The CA defines what misuse means.
A number of CAs define misuse as "used for purposes other than TLS web server"
Ergo, obtaining and using ce
On Jan 15, 2020, at 11:07 PM, Benjamin Kaduk wrote:
> Is there anything better for implementations to actually do (as distinct
> from what we write down as recommendations) than to start setting up a
> parallel (purpose-specific) PKI now and trusting that in parallel with what
> they're currently
A couple things that stand out to me from having basically read the whole
thread in one go (this is not intended to be an exhaustive list of open
questions):
It was implied but not fully clear to me, that Ryan thinks that someone so
inclined could, right now, go around trying to connect to wifi us
There has been a lot of discussion on this thread, but I do not see
anything actionable for the EAP-TLS 1.3 specification.
Joe
On Wed, Jan 8, 2020 at 12:48 PM Alan DeKok
wrote:
> On Jan 8, 2020, at 3:00 PM, Michael Richardson
> wrote:
> >
> >
> > Alan DeKok wrote:
> >alan> Many people use
On Jan 8, 2020, at 3:00 PM, Michael Richardson wrote:
>
>
> Alan DeKok wrote:
>alan> Many people use private CAs. Many use public CAs. *All* of them
>alan> use id-kp-serverAuth. Common EAP supplicants (MS / Apple / etc.)
>alan> ship with known root CAs. These root CAs are truste
Alan DeKok wrote:
alan> Many people use private CAs. Many use public CAs. *All* of them
alan> use id-kp-serverAuth. Common EAP supplicants (MS / Apple / etc.)
alan> ship with known root CAs. These root CAs are trusted by default
alan> for web browsing. None are trusted by def
On Jan 8, 2020, at 11:29 AM, Ryan Sleevi wrote:
> On Wed, Jan 8, 2020 at 10:38 AM Alan DeKok wrote:
> The rest of the disagreement is (from what I see), bringing up situations
> or use-cases which are unrelated to EAP, and therefore confusing the issue.
>
> They're related to the proposal tha
On Wed, Jan 8, 2020 at 10:38 AM Alan DeKok
wrote:
> The rest of the disagreement is (from what I see), bringing up
> situations or use-cases which are unrelated to EAP, and therefore confusing
> the issue.
>
They're related to the proposal that started this thread, which I'm trying
to focus th
To clarify. we agree on the following:
* id-kp-serverAuth is wrong to use for EAP
* we should use something else, whatever that is
The rest of the disagreement is (from what I see), bringing up situations or
use-cases which are unrelated to EAP, and therefore confusing the issue.
On Jan 8,
On Wed, Jan 8, 2020 at 8:14 AM Alan DeKok wrote:
> Except, of course, CAs don't really have a process to issue certs with
> distinct EKUs. So they're impossible to get in practice.
>
I'm not sure what your data to support this is, but this does not match the
commercial space. While I think we
On Jan 8, 2020, at 3:11 AM, Ryan Sleevi wrote:
> However, if using the same set or CAs that popular OSes use for TLS, it does
> mean that these CAs, and their customers, will still be subject to the same
> agility requirements, and limited to the same profile as TLS. Because of
> this, there’s
Thanks, Ryan. After I sent the note I thought about document signing. Our
SUDI model at Cisco I view as somewhat different, but may be closer to apt to
EAP anyway, so worth discussing.
Eliot
On 8 Jan 2020, at 12:26, Ryan Sleevi
mailto:ryan-i...@sleevi.com>> wrote:
On Wed, Jan 8, 2020 at 5
On Wed, Jan 8, 2020 at 5:00 AM Eliot Lear (elear) wrote:
> Hi Ryan,
>
> This topic seems like a good one to just get on the phone and sort
> through, but I have one question:
>
> On 8 Jan 2020, at 09:11, Ryan Sleevi wrote:
>
> However, if using the same set or CAs that popular OSes use for TLS,
Hi Ryan,
This topic seems like a good one to just get on the phone and sort through, but
I have one question:
On 8 Jan 2020, at 09:11, Ryan Sleevi
mailto:ryan-i...@sleevi.com>> wrote:
However, if using the same set or CAs that popular OSes use for TLS, it does
mean that these CAs, and their c
On Tue, Jan 7, 2020 at 9:00 PM Alan DeKok wrote:
> > The question posed in that original message is what to do with extant
> certificates and extant practices, such as going to CAs used for TLS and
> asking for an id-kp-serverAuth cert, or supplicants looking for
> id-kp-serverAuth, and whether t
On Jan 7, 2020, at 4:34 PM, Ryan Sleevi wrote:
>
> I've snipped your message, because I think we've gotten to a place where
> we're clearly talking past each other, as you claim I've said several things
> which I've most definitely not said, or expressed the opposite view. I'm
> hoping a reset
Hi Alan,
I've snipped your message, because I think we've gotten to a place where
we're clearly talking past each other, as you claim I've said several
things which I've most definitely not said, or expressed the opposite view.
I'm hoping a reset here might help us find a more productive path forw
On Jan 7, 2020, at 2:19 PM, Ryan Sleevi wrote:
> Was there a typo here? I’m not sure how to parse or understand this?
I read your previous messages as claiming there were issues *specific* to EAP
using id-kp-serverAuth. When I asked for specifics, the response was to
describe general issues
On Tue, Jan 7, 2020 at 12:51 PM Alan DeKok
wrote:
> On Jan 7, 2020, at 12:33 PM, Ryan Sleevi wrote:
> > > At the high-level, I will say that using TLS (id-kp-serverAuth)
> certificates, from the intersection of CAs that are commonly trusted by
> operating systems and browsers, is bad. It will cr
On Jan 7, 2020, at 12:33 PM, Ryan Sleevi wrote:
> > At the high-level, I will say that using TLS (id-kp-serverAuth)
> > certificates, from the intersection of CAs that are commonly trusted by
> > operating systems and browsers, is bad. It will create security issues,
> > will create interoperab
On Tue, Jan 7, 2020 at 11:44 AM Alan DeKok
wrote:
> On Jan 7, 2020, at 9:54 AM, Ryan Sleevi wrote:
> > At the high-level, I will say that using TLS (id-kp-serverAuth)
> certificates, from the intersection of CAs that are commonly trusted by
> operating systems and browsers, is bad. It will creat
On Jan 7, 2020, at 9:54 AM, Ryan Sleevi wrote:
> At the high-level, I will say that using TLS (id-kp-serverAuth) certificates,
> from the intersection of CAs that are commonly trusted by operating systems
> and browsers, is bad. It will create security issues, will create
> interoperability iss
Hi Owen,
While I have responses inline below, I am concerned that if I'm disagreeing
so much with you, there might be some high-level impedance mismatches that
we should get sorted first.
At the high-level, I will say that using TLS (id-kp-serverAuth)
certificates, from the intersection of CAs th
On Jan 7, 2020, at 8:53 AM, Owen Friel (ofriel) wrote:
> [ofriel] That’s pretty much it. For supplicants running on standard OSes
> (Windows, MacOS, iOS, Android), they could use logic similar to Chromium
> (which you must be familiar with seeing as you helped write it:
> https://github.com/chr
Thanks for the detailed reply Ryan. See line.
> -Original Message-
>
> If an EAP server operator wants to use a public CA identity cert on their EAP
> server, what recommendations should we give to EAP clients so that the
> supplicant code can handle public or private CA issued EAP serve
On Dec 15, 2019, at 6:43 PM, Ryan Sleevi wrote:
> That is, most definitions for “public CAs” come down to “I don’t want to
> think about / analyze the security or validation practices of the CA, I want
> my supplicant / software / hardware vendor to do it for me, against some
> criteria the ven
On Sun, Dec 15, 2019 at 4:01 PM Owen Friel (ofriel)
wrote:
> Hi,
>
>
>
> At ACME meeting at IETF106, the last discussion of the week was around EMU
> looking for recommendations for EAP client/peer/supplicant cert
> verification logic when the client is verifying the cert that the EAP
> server pr
69 matches
Mail list logo
