[TLS]Re: Curve-popularity data?

[Mike Shaver]

On Wed, Jun 5, 2024 at 9:19 AM Peter Gutmann 
wrote:

> Nick Harper  writes:
>
> >I see no requirement in section 9 nor in section 4.2.8 requiring MTI
> curves
> >be present in the key_share extension if that extension is non-empty.
>
> Just because it's possible to rules-lawyer your way around something
> doesn't
> make it valid (I also see nothing in the spec saying a TLS 1.3
> implementation
> can't reformat your hard drive, for example, so presumably that's OK too).
> The point is that P256 is a MTI algorithm and Chrome doesn't provide any
> MTI
> keyex in its client hello, making it a noncompliant TLS 1.3 implementation.


Hi Peter,

As you describe it, this seems like a somewhat material issue in Chrome’s
TLS 1.3 support, which I confess is surprising to hear about given Google’s
experience and level of investment in that space.

You mentioned in another message that some embedded TLS implementations
also omit MTI support for code size or attack surface reasons. Not to ask
you to speak for Chrome (though perhaps someone else on this list might be
able to!), but do you have any sense of why Chrome chose to omit this MTI
support?

Mike
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Trust Expressions Update

[Mike Shaver]

I think this highlights the importance of TLS as a specification used on
the web (versus being used an arbitrary protocol between two endpoints)
being explicit about what assumptions it is making about how root programs
are operated, and how the choices of those root programs manifest for
users. I can understand, and indeed share, a reluctance to design user
interfaces guidelines in RFC text, but I think that it would be valuable to
at least indicate at SHOULD strength where an unexpected trust decision
might be made based on server-originated protocol elements.

This would also, I think, be helpful to root programs in auditing their
practices to make sure that the trust decisions that are being made on
behalf of their users are kept intact through the various protocol
operations.

Mike

On Fri, Jul 19, 2024 at 7:06 PM Ryan Hurst  wrote:

> The risks of eIDAS did not come from the existence of a trust list, nor
> would they have been amplified by server adoption or negotiation mechanisms
> for the trust list. The existence of a trust anchor negotiation mechanism
> such as Trust Expressions does not change the fact that the security risk
> continues to be from mandated, unconditional, unrestricted trust of abusive
> CAs on the client, not the server. The risk of client trust in an abusive
> CA is not affected by the server deployment of that abusive CA, nor is it
> affected by a negotiation mechanism for the server to select a certificate
> from the abusive CA.
>
> For those unfamiliar with eIDAS 2.0 and this topic you might want to see:
> -
> https://docs.google.com/document/d/1sGzaE9QTs-qorr4BTqKAe0AaGKjt5GagyEevDoavWU0
> -
> https://securityriskahead.eu/wp-content/uploads/2024/02/Mozilla_-press-release_eIDAS-EP-Plenary-adoption.pdf
> -
> https://www.europarl.europa.eu/doceo/document/A-9-2023-0038-AM-007-007_EN.pdf
>
> While the latest version of eIDAS was not an attempt at mass surveillance,
> it was a clumsy attempt at distributed regulatory capture and “strong
> identity” for EU ecommerce sites without adequate controls to manage the
> associated risks. This proposal had the side effect of making it easier for
> countries to silently deploy mass surveillance via blind man-in-the-middle
> (MITM) attacks through legally mandated government CAs on the client. One
> of the available mitigations against this abuse can be found in Certificate
> Transparency, or at least the promise of it. Since the early legislation
> precluded root programs from enforcing additional controls, and QWACs are
> not CT logged today unless they are part of the root programs, it wouldn't
> have been an effective mitigation. Furthermore, since browsers may have
> been prohibited from distrusting the legally mandated CAs, these attacks
> could have gone on indefinitely.
>
> That said, as long as all certificates are logged in CT, the Certificate
> Transparency ecosystem remains healthy enough to deliver on its promises,
> and if browsers are still able to distrust CAs found guilty of abuse, we
> would have the ability to detect and respond to these cases. The mandated
> trust in eIDAS would actually be the same conditional trust applied to all
> CAs today, with the same risks as any other CA.
>
> The security risks from eIDAS depend on whether or not the user agent is
> free to enforce security requirements on the contents of the root store,
> including distrust, in order to prevent interception and remove CAs that
> fail to meet the requirements, including not to MITM. The risk is that root
> store trust is mandated unconditionally.
>
> It is also worth noting that RFC 7258 on preventing pervasive monitoring
> has been cited several times as part of the arguments against Trust
> Expressions. However, it clearly states:
>
> Moreover, the non-technical (e.g., legal and political) aspects of
> mitigating pervasive monitoring are outside of the scope of the IETF.
>
> Speculation about how a server negotiation mechanism or server deployment
> of an otherwise untrusted government CA might later affect a root store's
> decision to include that CA, and whether or not that will make it easier to
> then pass laws preventing the distrust of that CA, seems fully into the
> legal and political aspects of mitigating pervasive monitoring and has
> nothing to do with the technical details of the client trust store and not
> Trust Expressions.
>
>
> Ryan Hurst
>
> On Thu, Jul 18, 2024 at 12:25 PM Dennis Jackson  40dennis-jackson...@dmarc.ietf.org> wrote:
>
>> On 29/06/2024 00:14, David Benjamin wrote:
>>
>> > We have published a second, related draft, TLS Trust Anchor
>> > Identifiers. This draft outlines a separate mechanism we had
>> > considered during the design of TLS Trust Expressions, and is intended
>> > to solve many of the same problems that Trust Expressions does. Some
>> > of the feedback we received about TLS Trust Expressions renewed our
>> > interest in this approach.
>>
>> I’ve reviewed the Trust Anchors draft and although I unders

[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks

[Mike Shaver]

On Sat, Jul 20, 2024 at 8:59 AM Ilari Liusvaara 
wrote:

> Allowing various embedded and IoT stuff to migrate off of WebPKI would
> be of immense value. Such stuff using WebPKI has been source of gigantic
> amount of pain.


I agree with your second sentence very much, but I don’t understand your
first one. In what way are these non-web systems not allowed to use other
PKI models today? How would trust anchors provide that permission?

Mike
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks

[Mike Shaver]

On Sat, Jul 20, 2024 at 2:23 PM David Benjamin 
wrote:

> On Sat, Jul 20, 2024, 06:13 Mike Shaver  wrote:
>
>>  In what way are these non-web systems not allowed to use other PKI
>> models today? How would trust anchors provide that permission?
>>
>
> If the same server serves both embedded/IoT traffic and web browser
> traffic, but we aim for the two to use different PKIs, the server needs to
> arrange to serve different certificates to each. To do that, we need trust
> anchor negotiation story.
>

If there is no extra-TLS means of distinguishing those cases, such as port
or IP addresses for endpoints, then today such a system can use SNI, which
is basically a very simple trust selection story. It is less flexible, but
for selecting between disjoint PKIs in which to orient a given connection,
it seems that it would suffice.

PayPal and Netflix semi-famously rolled out SNI at moderate pain to
accommodate a pretty similar situation when browsers and their IOT/etc
devices no longer had trusted roots in common. I am not against TAs as a
more flexible way to negotiate the PKI properties that the participants
want to use for their connection, but I think it's counterproductive to the
health of the web PKI to spread the idea that TA is *required* for systems
to migrate to non-web PKI, even if they indeed need to keep using the same
endpoints for some reason. Having those systems that are inappropriately
using web PKI today justify further such misuse by saying that they are
waiting for all their systems to support TA would be pretty unfortunate. I
think that practically the process of managing and deploying new roots and
certificates for a private PKI will make "change the hostname or port used"
a small additional matter.

To be clear, I think that TA will make it easier to resolve such misuses,
and that this is a virtue of the proposal. I just really don't like the
idea that it's not possible today.

On Sun, Jul 21, 2024 at 7:05 PM Dennis Jackson  wrote:

> We've seen a number of recent incidents where CAs have delayed revocation
> of mis-issued certificates for 'critical' services that are not accessible
> on the public web [1]. The vast majority of these services could already
> migrate to a private PKI today but they simply don't have adequate
> incentives to make the small investment necessary. How would Trust
> Expressions or Trust Anchors change that?
>
TA, once deployed, could well possibly make it easier to migrate or manage
such systems, but I don't think it's reasonable to expect that any protocol
change will provide sufficient "incentive" for the operator of such a
system to bear the costs of operating a PKI when they could instead push
those costs to the stewards of the web PKI instead. It's not a reasonable
standard against which to evaluate a protocol element, IMO.

Mike


On Sat, Jul 20, 2024 at 2:23 PM David Benjamin 
wrote:

> On Sat, Jul 20, 2024, 06:13 Mike Shaver  wrote:
>
>>
>>
>> On Sat, Jul 20, 2024 at 8:59 AM Ilari Liusvaara 
>> wrote:
>>
>>> Allowing various embedded and IoT stuff to migrate off of WebPKI would
>>> be of immense value. Such stuff using WebPKI has been source of gigantic
>>> amount of pain.
>>
>>
>> I agree with your second sentence very much, but I don’t understand your
>> first one. In what way are these non-web systems not allowed to use other
>> PKI models today? How would trust anchors provide that permission?
>>
>> Mike
>>
>
> If the same server serves both embedded/IoT traffic and web browser
> traffic, but we aim for the two to use different PKIs, the server needs to
> arrange to serve different certificates to each. To do that, we need trust
> anchor negotiation story.
>
> David
>
>
>
> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks

[Mike Shaver]

On Mon, Jul 22, 2024 at 12:52 PM David Benjamin 
wrote:

> I say sometimes because this is not always viable. It's a more indirect
> way of addressing the root issue, so there are some limitations. First,
> this requires foresight on the part of the service operator and client
> vendor. If everyone knew ahead of time that the client might diverge (e.g.
> by way of standing still while the ecosystem moves), then one might set
> this up. But this is a perennial problem *because* people empirically do
> not know ahead of time. Or perhaps the vendor even intended to continue
> servicing their IoT devices, went out of business, but enough folks bought
> them and continue to happily use them that some other service provider does
> not wish to abandon them.
>
> We can try to help this by encouraging such foresight as best practice,
> but it takes just one important client of one important server to gum up
> the works. Trust anchor negotiation, if successful, provides a solution
> that doesn't require as much deployment-level foresight. (If the IoT device
> can negotiate trust anchors, it's easy. If it can't, the clients that *do* 
> negotiate
> trust anchors can still evolve freely and do not add to the PKI
> intersection problem.)
>

Yep, I absolutely look forward to a web where we have this sort of
capability, either on endpoints themselves or even managed by a more-modern
intermediary. I’m not informed enough to comment on the protocol elements
of the specific Trust Anchor proposal, but I agree that more PKI agility
will be healthy.

Fundamentally, the TLS implementation community will be pushing this
agility into endpoints by default, which means that it would take active
divergence by a system implementor to create the sort of TBTF systems that
impede trust changes today.

Mike
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks

[Mike Shaver]

On Mon, Jul 22, 2024 at 1:36 PM Dennis Jackson  wrote:

> I would like to hear from the authors (or others in the TLS implementation
> community) if they think Trust Expressions / Trust Anchors can be pushed
> into non-browser endpoints by default and the work they think would be
> required to achieve it?
>
> I think I see how, with substantial investment, an application like a
> browser could adopt these designs. I'm not sure I can see a TLS library
> ever being able to offer it by default.
>

Today, TLS libraries used in “general purposes” systems, like the default
HTTP libraries or such for languages, have a pretty simple model of trust:
list of certs, each with notBefore/notAfter/eku at best. Already that lags
behind some of the nuance that web browsers use, whether Mozilla’s simple
notBefore-of-issued-cert measure, or Chrome’s more complex SCT time
validation.

As an example, the popular Python package “certifi” provides a set of
“curated” roots, which is actually the Firefox root set. When Firefox
stopped trusting certificates issued by “e-commerce management” after a
certain date, that package removed the root entirely, meaning that unlike
with Firefox (and Chrome), all previously issued certificates were also
rejected.

We’re in the early days of these “bounded trust” capabilities, and I have
some hope that we will settle into a small number of additional rules that
are sufficient to make root distrust (or scope reduction) easier on the
ecosystem. At that point, libraries like OpenSSL will need to decide if
they want to be able to reflect the web PKI (as interpreted by at least one
browser, anyway), in which case they will need to add these sorts of
checks, and root store providers will need to configure them. Maybe we end
up with a standard language for expressing them, but root stores already
differ in format today without much pain, so I don’t think that’s
necessary. I think that most program authors who use these “standard” TLS
implementations are generally expecting to validate as a browser would,
unless they take additional steps, so I see this lack as a bug in those
libraries, or at least a capability that needs to be easily available in
each stack ecosystem.

Trust Anchor negotiation will require configuration of both sides, but so
does cipher negotiation and so forth, and I think that it will be fine for
a library to come with “sane, web-like” defaults, and then provide a
mechanism for configuring alternative policies when desired.

Whether it should be or not, especially given recent events, it’s generally
easier to get a configuration change deployed than a software update. But
also, even if the legacy endpoints never get a trust anchors configuration
update or support, those that *do* support it can be treated appropriately
without disrupting the frozen clients. This would let modern clients like
browsers continue to tend to the web PKI, without the opposing force of
such possible disruptions. From my experience with root programs, this
would be a very welcome capability!

Mike
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH

[Mike Shaver]

Yeah, I think we will see more inadvertent logging than malicious, just as
we have seen passwords mistakenly deposited in logs for approximately as
long as we have had both logs and passwords.

One challenge with SSLKEYLOG is that there’s no way without very
system-specific inspection to detect whether it’s on or off (as compared to
“supposed to be on or off, as we intended to deploy”). It would certainly
be a bigger specification, but I think it would be nice if there were some
marker in the TLS handshake that indicated that SSLKEYLOG was in effect. It
would be even nicer if that marker were visible to observers who don’t have
the keys, so that packet-inspection sorts of rules could detect and alert
on it, but TLS is generally moving in the other direction in terms of
having things outside the encryption envelope.

Mike

On Sun, Aug 4, 2024 at 10:41 AM Amir Omidi  wrote:

> It doesn’t necessarily need to be malicious. With how much of software
> deployment being massive YAML files with tons of environment variables,
> mistakenly including this won’t be that difficult.
>
> On Sun, Aug 4, 2024 at 07:00 Ilari Liusvaara 
> wrote:
>
>> On Sat, Aug 03, 2024 at 02:38:29PM -0700, Christian Huitema wrote:
>> >
>> > The security considerations of
>> > https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ are pretty
>> > clear, but the discussion pointed out that environment variables can be
>> > installed without knowledge of most users. More protection is needed.
>> > Examples are explicit run time options, such as asking the user to set a
>> > special configuration flag to enable the feature, and compile time
>> > protections, which would only enable that configuration flag in special
>> > versions of the application.
>>
>> Any attacker that can tamper with environment variables is in position
>> to do way way worse things than enabling SSLKEYLOG. Possibly even worse
>> than an attacker capable of replacing the whole application with a
>> troijan!
>>
>>
>>
>>
>> -Ilari
>>
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXTERNAL] Re: Is there any interest in an RFC on how to do cross-organization mTLS?

[Mike Shaver]

Public CAs not only add another risk, but public CAs shouldn't want to be
issuing these anyway if they are not for use with the web PKI. I agree that
it doesn't seem in scope for the IETF's work, but I'll admit that I'd love
to see more advocacy for divorcing such configurations from the public web
PKI...

Mike

On Mon, Sep 16, 2024 at 10:33 AM Richard Barnes  wrote:

> Thanks for the additional details, Mark.  So it sounds like these
> organizations are not only requiring that the remote party's certificate be
> issued by a public CA, but that it be a specific certificate.
>
> Couple of observations here:
>
> 1. This is clearly not business for the TLS WG.  This WG doesn't do
> anything with how certificate trust is provisioned.  UTA might be right, or
> just run through the DISPATCH process.
>
> 2. This seems like a terrible design.
> * It's basically HTTP certificate pinning [RFC7469], which is being
> aggressively deprecated by browsers for exactly the downtime reasons you
> mention.
> * The public CA isn't adding any value here, and as you note, they add
> to the downtime risk
> * Trying to automate this is pointless, because you'll just end up
> back at the same problem of establishing trust with the other side.  If you
> had an automated "here's my new cert" protocol, well, how do you verify
> that the thing sending you the new cert is authorized to?
>
> In light of (2), I would be disinclined for the IETF to do any work on
> this particular flavor of the mTLS problem.
>
>
> On Fri, Sep 13, 2024 at 11:08 PM Mark Robinson 
> wrote:
>
>> I want to thank everyone for your feedback. It's been super helpful.
>>
>> I think I should elaborate on what the problem is and how it can be fixed.
>>
>> I've worked with a lot of companies who want to use mTLS (as bas as the
>> name is) to increase security but don't know how to do it in a way that
>> won't reduce reliability. For example, many companies require a certificate
>> signed by a public CA and then *emailed* to them. They have the annual cert
>> expiry of a regular cert combined with a manual (and hackable process) that
>> basically  guarantees downtime when someone goes on vacation.
>>
>> What I'd like to cover:
>> - How two orgs (that aren't CAs) can exchange keys
>> - How to rotate keys
>> - What parameters keys should be set, and how keys should be validated
>> - When and how keys should be updated
>> - All of this without manual steps or #$%#$%ing email.
>>
>> Setting up cross-validation of TLS should be a single line change for
>> high performing organizations and should never, ever, ever involve email
>> certs between customer service reps.
>>
>> Mark
>>
>> On Wed, Sep 11, 2024 at 4:30 PM Peter Gutmann 
>> wrote:
>>
>>> Andrei Popov  writes:
>>>
>>> >I'm with Richard on this one. Not a fan of the "mTLS" concept: it causes
>>> >confusion where customers ask whether "mTLS" is a different protocol or
>>> a
>>> >specific TLS implementation? However, it can be argued that this
>>> unfortunate
>>> >term has already taken root.
>>>
>>> +1, Richard pretty much said everything I have concerns about but saved
>>> me a
>>> lot of typing.  mTLS *is* TLS, there's no need to give it a special name
>>> for
>>> marketing(?) purposes.
>>>
>>> Having said that, I'd have no problems with a "TLS Profile for xxx",
>>> which is
>>> what it really seems to be.
>>>
>>> (And I'll add an obligatory comment that what (m)TLS does isn't mutual
>>> authentication, it's unidirectional authentication in both directions,
>>> but
>>> that boat has long since sailed.  If you wanted to have actual mTLS it'd
>>> have
>>> to use PSK).
>>>
>>> Peter.
>>> ___
>>> TLS mailing list -- tls@ietf.org
>>> To unsubscribe send an email to tls-le...@ietf.org
>>>
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: PKI dynamics and trust anchor negotiation

[Mike Shaver]

Hi Watson,

On Thu, Feb 6, 2025 at 8:10 PM Watson Ladd  wrote:

> A negotiation where what is advertised is an inherently opaque
> pointer, and where each side must maintain an idea of what that could
> mean, does not have this property. Servers have to explicitly act to
> support the new identifier by getting a configuration that includes
> it. Whether or not this is indirectly away as part of ACME doesn't
> really change the equation. New clients can't count on server support,
> unless they advertise an already existing value. There's been various
> ways to express deltas to try to solve this, but they all involve
> paying a penalty for deviation.
>
> The dynamic I'm worried about most then isn't fracturing: as you point
> out there are some countervailing forces where people want easy
> support. Rather it's that we artificially drive up the price of
> picking different CAs than the dominant implementation.


I very much share the concerns you've articulated here: increased barriers
to entry both for new CAs and for new clients which have different
root-management policies than the existing dominant implementation, and
outsized penalties for differing from a "well-known set" as might happen
from having tighter requirements on CA operation over time. The opaque
token seems like it could lead to the properties that you (and I) wish to
avoid, but when expressing my support for the group taking up the draft, I
felt that the specific identifier form for trust anchors was still mutable,
and therefore that it wasn't a barrier to draft adoption.

If I have misunderstood, and identifiers must inherently be opaque in that
way for all forms of trust anchors negotiation, then I appreciate the
correction!

Mike
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption Call for Trust Anchor IDs

[Mike Shaver]

I support adoption. Cross-signing has proven a clumsy tool for managing the
introduction of new roots, and we need something better.

Mike


On Wed, Jan 15, 2025 at 11:01 AM Joseph Salowey  wrote:

> At the trust tussle Interim in October we had consensus that the working
> group was interested in working on the following problem:
>
> “Avoid client trust conflicts by enabling servers to reliably and
> efficiently support clients with diverse trust anchor lists, particularly
> in larger PKIs where the existing certificate_authorities extension is not
> viable”
>
> After IETF 121, we asked for submissions for possible working group
> adoption as a starting point for this work. We received two submissions:
>
> [1] Trust Anchor Identifiers, draft-beck-tls-trust-anchor-ids-03
> 
>
> [2] Trust is non-negotiable, draft-jackson-tls-trust-is-nonnegotiable-00
> 
>
> [1] defines a new protocol mechanism, while [2] provides an explanation of
> why the mechanism in [1] may not be needed and may be problematic. Since
> the second draft does not define a protocol mechanism we are not
> considering it for adoption, but we request that working group members
> review both documents and use [2] as input into determining whether we
> should adopt [1] as a working group item.  Adoption as a working group item
> means the working group has change control over and can modify it as
> necessary; an adopted document is only a starting point.  Please respond to
> this thread if you think the document should be adopted as a working group
> item. If you think the document is not appropriate for adoption please
> indicate why.  This adoption call will close on February 7, 2025.  Also
> please remember to maintain professional behavior and keep the discussion
> focused on technical issues.
>
>
> Thanks,
>
>
> Sean, Deirdre and Joe
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

[Mike Shaver]

It's interesting, IMO, that there is so much belief that an RFC designation
will drive so much adoption here, but it didn't seem to be the same
consensus that enshrining SSLKEYLOGFILE in an RFC might increase the number
of systems that support key exfil.

To be sure, I don't confidently know which is the case; perhaps both,
though I can't figure out how to reconcile that myself at this point.

Mike

On Wed, Feb 26, 2025 at 10:16 PM Peter Gutmann 
wrote:

> Jan Schaumann  writes:
>
> >It may seem silly to all folks who are directly involved here in these
> >discussions, but many software and service providers view a "draft" as
> >immature, not final, subject to change and may not implement until it has
> an
> >RFC number.
>
> This is standard policy for a number of organisations I deal with: If it's
> not
> a published standard (ISO, IEEE, RFC), it doesn't get considered.  They
> don't
> sell products based on drafts.
>
> (Actually for IEEE stuff at least one of them pre-implements based on
> drafts
> so they're ready for market when it's finalised, but that's splitting
> hairs).
>
> Peter.
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: I-D Allow using serverAuth certificates for mutual TLS (mTLS) authentication in server-to-server usages - updates rfc5280 and rfc6066

[Mike Shaver]

On Thu, Jun 19, 2025 at 8:33 AM Viktor Dukhovni 
wrote:

> On Thu, Jun 19, 2025 at 05:30:16AM -0700, Watson Ladd wrote:
>
> > The WebPKI is the universe of CAs that issue certs that browsers trust.
> > They don't care about anything outside that.
>
> Well, that's disconnected from the reality that the mainstream operating
> systems are shipping the same roots broadly for TLS, and the "Web" PKI,
> is far from Web-only.


This sounds like an issue to be taken up with the operating system vendors,
by their customers, and not one that is appropriate to address through
changes to TLS-related specifications or the (already complex) requirements
for the Web PKI. I believe every operating system already ships
certificates or keys of some kind that aren’t universally trusted by
browsers, such as for verifying updates, so they have some facility for it.

The operators of those browser root stores have for some time warned
against exactly this situation, where using the Web PKI just because “it’s
already there” was going to lead to painful misalignment for those who
wanted the convenience of reusing the PKI, but didn’t want to continue to
accept its rules. Another example of this is use of SCT-based distrust
mechanisms, which do not have a standardized expression in a cert store and
therefore are not automatically honoured by all TLS implementations. This
leads operating systems and similar which naively repackage a browser’s
root store to trust certificates that browsers have gone to some lengths to
distrust. The solution again is “don’t do that naive reuse”.

Mike
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org