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 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
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 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
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
{I've intentionally broken the thread, and I'm restarting the discussion.
Please forgive the length}
Alan DeKok wrote:
>> Certainly, some of the excitement for ACME/Letsencrypt with DNS-01
challenge
>> is that it makes it easy to get a certificate for a non-HTTP thing.
>>
>> I t
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 5:19 PM, Michael Richardson wrote:
> } c) supplicants do not check DNS names or any other field in the
> certificates
> } d) as a result of this lack of verification, supplicants ship with all
> known
> } CAs disabled for TLS-based EAP methods"
For (d), CAs are disab
Michael Richardson wrote:
> 3. End User Client Certificates
> A client certificate used to authenticate an end user may be used for
> mutual authentication in TLS, ***EAP-TLS***, or messaging. The client
> (to be very very very clear: not a consensus document at this point
Hi Michael,
You mention in a couple places that EAP server certificate should be
identifying an rfc822Name DN, and I think I'm confused about what you mean.
(I suspect I'm seeing "rfc822Name" and jumping to what ACP does, which is
wrong.) Could you walk through an example of what that would look
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
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
12 matches
Mail list logo
