[TLS]Re: [EXTERNAL] Re: WG Adoption for TLS Trust Expressions

[Carl Wallace]

 

 

From: Joseph Salowey 
Date: Wednesday, May 22, 2024 at 5:04 PM
To: "tls@ietf.org" 
Subject: [TLS]Re: [EXTERNAL] Re: WG Adoption for TLS Trust Expressions

 

Thanks to the working group for all the discussion on this document. We will 
kick off an official adoption call soon. While this work is clearly applicable 
to TLS, the topic of trust stores is broader. 

 

[CW] Path building is broader too. 

 

The working group should be aware that if the document is adopted as a working 
group item, It's possible that work will be identified that would be better 
addressed in other forums. It is also possible that this situation will not 
arise and all the work will be completed in TLS. 

 

On Wed, May 22, 2024 at 8:45 AM Andrei Popov 
 wrote:

While a TLS extension could be used to identify which 
approaches/algorithms/protocols the client supports, the server also needs to 
know which of its certificate chains the client trusts.
To me, these are two separate issues: 
Selecting a certificate chain based on the client’s signature suite support and 
Selecting a certificate chain the client trusts.
 

#1 is already solved: we have signature_algorithms_cert and 
signature_algorithms extensions. Some TLS implementations have support for 
deploying multiple cert chains per endpoint and selecting the appropriate cert 
chain based on peer-supported signature suites. This should work fine for PQC, 
once we define PQC and hybrid SignatureScheme code points.

 

#2 has an existing solution as well (certificate_authorities extension), but in 
practice it’s not efficient and in some cases not secure. This is where we need 
improvement and Trust Expressions appears to be an option, although we will 
likely want to change the details of the design a bit and make it better.

 

Cheers,

 

Andrei

 

From: Nick Harper  
Sent: Tuesday, May 21, 2024 11:29 PM
To: Dennis Jackson 
Cc: tls@ietf.org
Subject: [EXTERNAL] [TLS]Re: WG Adoption for TLS Trust Expressions

 

You don't often get email from i...@nharper.org. Learn why this is important
On Tue, May 21, 2024 at 3:00 PM Dennis Jackson 
 wrote:

This thread is now 40+ messages deep and I guess you might have not seen much 
of the previous discussion. I actually agree with much of your analysis, but it 
focused on the wrong question, as I wrote earlier in this thread:

The question we're evaluating is NOT "If we were in a very unhappy world where 
governments controlled root certificates on client devices and used them for 
mass surveillance, does Trust Expressions make things worse?" Although Watson 
observed that the answer to this is at least 'somewhat', I agree such a world 
is already maxed at 10/10 on the bad worlds to live in scale and so it's not by 
itself a major problem in my view.

I don't see Watson saying that in any of his messages [5] [6] [7]. Message [7] 
does mention an intermediate cross-signed by a government CA, but my 
understanding of Watson's argument is that Trust Expressions doesn't do 
anything to enable that since the "chain" of certificates sent by a TLS server 
is really just a grab bag for the client to use when it does path building. 
Specifically, in today's world, a CA could send to ACME clients a leaf cert 
with intermediates and cross-signs so that the root of the path could be either 
that CA or a government CA, and when that server sends that bag of 
intermediates to a client to verify, the client will build one of those two 
paths, depending on what's in the client's trust store.


The actual concern is: to what extent do Trust Expressions increase the 
probability that we end up in this unhappy world of government CAs used for 
mass surveillance?

This is a good question to ask, and I see you attempted to address it in 
message [4]. You argue that Trust Expressions provides an "on-ramp" for 
deploying a government CA to reach a certain level of legitimacy or adoption. I 
don't see the connection between that and mass surveillance, nor do I see you 
make a claim that Trust Expressions does increase this probability. In [1] you 
describe this "on-ramp", which has step 1 being to ship support for trust 
negotiation (which could be more accurately described as a trust store 
advertisement mechanism), and step 2 as the following:

 

>  * A large country or federation pushes for recognition of their
>domestic trust regime as a distinct trust store which browsers must
>advertise. Browsers agree because the relevant market is too big to
>leave.

 

I see two ways this happens: The first is that the recognition of the domestic 
trust regime is done in a way that does not circumvent root store policy. By 
this, I mean that the CAs in this domestic trust regime must meet all audit and 
other policy requirements of the browser's root store, and a brower root store 
can remove trust in a CA from that set if it violates the root store 
requirements (in the same way that root stores currently operate to distrust a 
CA when it is no 

[TLS]Re: [EXTERNAL] Re: WG Adoption for TLS Trust Expressions

[Joseph Salowey]

Thanks to the working group for all the discussion on this document. We
will kick off an official adoption call soon. While this work is clearly
applicable to TLS, the topic of trust stores is broader. The working group
should be aware that if the document is adopted as a working group item,
It's possible that work will be identified that would be better addressed
in other forums. It is also possible that this situation will not arise and
all the work will be completed in TLS.

On Wed, May 22, 2024 at 8:45 AM Andrei Popov  wrote:

>
>- While a TLS extension could be used to identify which
>approaches/algorithms/protocols the client supports, the server also needs
>to know which of its certificate chains the client trusts.
>
> To me, these are two separate issues:
>
>1. Selecting a certificate chain based on the client’s signature suite
>support and
>2. Selecting a certificate chain the client trusts.
>
>
>
> #1 is already solved: we have signature_algorithms_cert and
> signature_algorithms extensions. Some TLS implementations have support for
> deploying multiple cert chains per endpoint and selecting the appropriate
> cert chain based on peer-supported signature suites. This should work fine
> for PQC, once we define PQC and hybrid SignatureScheme code points.
>
>
>
> #2 has an existing solution as well (certificate_authorities extension),
> but in practice it’s not efficient and in some cases not secure. This is
> where we need improvement and Trust Expressions appears to be an option,
> although we will likely want to change the details of the design a bit and
> make it better.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Nick Harper 
> *Sent:* Tuesday, May 21, 2024 11:29 PM
> *To:* Dennis Jackson 
> *Cc:* tls@ietf.org
> *Subject:* [EXTERNAL] [TLS]Re: WG Adoption for TLS Trust Expressions
>
>
>
> You don't often get email from i...@nharper.org. Learn why this is
> important 
>
> On Tue, May 21, 2024 at 3:00 PM Dennis Jackson  40dennis-jackson...@dmarc.ietf.org> wrote:
>
> This thread is now 40+ messages deep and I guess you might have not seen
> much of the previous discussion. I actually agree with much of your
> analysis, but it focused on the wrong question, as I wrote earlier in this
> thread:
>
> The question we're evaluating is NOT "If we were in a very unhappy world
> where governments controlled root certificates on client devices and used
> them for mass surveillance, does Trust Expressions make things worse?"
> Although Watson observed that the answer to this is at least 'somewhat', I
> agree such a world is already maxed at 10/10 on the bad worlds to live in
> scale and so it's not by itself a major problem in my view.
>
> I don't see Watson saying that in any of his messages [5] [6] [7]. Message
> [7] does mention an intermediate cross-signed by a government CA, but my
> understanding of Watson's argument is that Trust Expressions doesn't do
> anything to enable that since the "chain" of certificates sent by a TLS
> server is really just a grab bag for the client to use when it does path
> building. Specifically, in today's world, a CA could send to ACME clients a
> leaf cert with intermediates and cross-signs so that the root of the path
> could be either that CA or a government CA, and when that server sends that
> bag of intermediates to a client to verify, the client will build one of
> those two paths, depending on what's in the client's trust store.
>
>
> The actual concern is: to what extent do Trust Expressions increase the
> probability that we end up in this unhappy world of government CAs used for
> mass surveillance?
>
> This is a good question to ask, and I see you attempted to address it in
> message [4]. You argue that Trust Expressions provides an "on-ramp" for
> deploying a government CA to reach a certain level of legitimacy or
> adoption. I don't see the connection between that and mass surveillance,
> nor do I see you make a claim that Trust Expressions does increase this
> probability. In [1] you describe this "on-ramp", which has step 1 being to
> ship support for trust negotiation (which could be more accurately
> described as a trust store advertisement mechanism), and step 2 as the
> following:
>
>
>
> >  * A large country or federation pushes for recognition of their
> >domestic trust regime as a distinct trust store which browsers must
> >advertise. Browsers agree because the relevant market is too big to
> >leave.
>
>
>
> I see two ways this happens: The first is that the recognition of the
> domestic trust regime is done in a way that does not circumvent root store
> policy. By this, I mean that the CAs in this domestic trust regime must
> meet all audit and other policy requirements of the browser's root store,
> and a brower root store can remove trust in a CA from that set if it
> violates the root store requirements (in the same way that root stores
> currently operate to 

[TLS]Re: [EXTERNAL] Re: WG Adoption for TLS Trust Expressions

[Andrei Popov]

  *   While a TLS extension could be used to identify which 
approaches/algorithms/protocols the client supports, the server also needs to 
know which of its certificate chains the client trusts.
To me, these are two separate issues:

  1.  Selecting a certificate chain based on the client’s signature suite 
support and
  2.  Selecting a certificate chain the client trusts.

#1 is already solved: we have signature_algorithms_cert and 
signature_algorithms extensions. Some TLS implementations have support for 
deploying multiple cert chains per endpoint and selecting the appropriate cert 
chain based on peer-supported signature suites. This should work fine for PQC, 
once we define PQC and hybrid SignatureScheme code points.

#2 has an existing solution as well (certificate_authorities extension), but in 
practice it’s not efficient and in some cases not secure. This is where we need 
improvement and Trust Expressions appears to be an option, although we will 
likely want to change the details of the design a bit and make it better.

Cheers,

Andrei

From: Nick Harper 
Sent: Tuesday, May 21, 2024 11:29 PM
To: Dennis Jackson 
Cc: tls@ietf.org
Subject: [EXTERNAL] [TLS]Re: WG Adoption for TLS Trust Expressions

You don't often get email from i...@nharper.org. Learn 
why this is important
On Tue, May 21, 2024 at 3:00 PM Dennis Jackson 
mailto:40dennis-jackson...@dmarc.ietf.org>>
 wrote:

This thread is now 40+ messages deep and I guess you might have not seen much 
of the previous discussion. I actually agree with much of your analysis, but it 
focused on the wrong question, as I wrote earlier in this thread:
The question we're evaluating is NOT "If we were in a very unhappy world where 
governments controlled root certificates on client devices and used them for 
mass surveillance, does Trust Expressions make things worse?" Although Watson 
observed that the answer to this is at least 'somewhat', I agree such a world 
is already maxed at 10/10 on the bad worlds to live in scale and so it's not by 
itself a major problem in my view.
I don't see Watson saying that in any of his messages [5] [6] [7]. Message [7] 
does mention an intermediate cross-signed by a government CA, but my 
understanding of Watson's argument is that Trust Expressions doesn't do 
anything to enable that since the "chain" of certificates sent by a TLS server 
is really just a grab bag for the client to use when it does path building. 
Specifically, in today's world, a CA could send to ACME clients a leaf cert 
with intermediates and cross-signs so that the root of the path could be either 
that CA or a government CA, and when that server sends that bag of 
intermediates to a client to verify, the client will build one of those two 
paths, depending on what's in the client's trust store.

The actual concern is: to what extent do Trust Expressions increase the 
probability that we end up in this unhappy world of government CAs used for 
mass surveillance?
This is a good question to ask, and I see you attempted to address it in 
message [4]. You argue that Trust Expressions provides an "on-ramp" for 
deploying a government CA to reach a certain level of legitimacy or adoption. I 
don't see the connection between that and mass surveillance, nor do I see you 
make a claim that Trust Expressions does increase this probability. In [1] you 
describe this "on-ramp", which has step 1 being to ship support for trust 
negotiation (which could be more accurately described as a trust store 
advertisement mechanism), and step 2 as the following:

>  * A large country or federation pushes for recognition of their
>domestic trust regime as a distinct trust store which browsers must
>advertise. Browsers agree because the relevant market is too big to
>leave.

I see two ways this happens: The first is that the recognition of the domestic 
trust regime is done in a way that does not circumvent root store policy. By 
this, I mean that the CAs in this domestic trust regime must meet all audit and 
other policy requirements of the browser's root store, and a brower root store 
can remove trust in a CA from that set if it violates the root store 
requirements (in the same way that root stores currently operate to distrust a 
CA when it is no longer trustworthy). In this case, I see no negative effect on 
security for users or the websites they are connecting to. From a technical 
perspective, this looks the same regardless of whether the Web PKI ecosystem 
supports a trust store advertisement mechanism. I see no change in the 
probability of ending up in the "unhappy world" in this way.

The second way this could happen is that the government compels a browser to 
add a CA to their root store regardless of whether it complies with root store 
policy, implicitly stating that this CA will misissue certificates. The 
browser's choice is to comply or leave the market. Until this new 

[TLS]Re: progressing -rrc

[Sean Turner]

> On May 22, 2024, at 10:09, Sean Turner  wrote:
> 
> Hi! If you recall we paused progressing -rrc [1] while we awaited 
> implementations.  Well, we now have that; we have one server and two clients 
> (all DTLS 1.2) [2]. However, we now also have the formal analysis triage 
> panel so we need to run the I-D through them.  Once we run the I-D through 
> that process we will revisit progressing the I-D.  I [have noted / will note] 
> in the datatracker that the document is awaiting external review.
> 
> Cheers,
> spt
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-rrc/
> [2] https://github.com/tlswg/dtls-rrc/issues/72

I should have added that we are sending this I-D to the formal analysis triage 
team because this I-D might be changing security assumptions in DTLS 1.3 or 
extending it and generally we want those sort of changes to TLS 1.3 evaluated.  
You’ll note we are not suggesting passing the Legacy RSASSA-PKCS1-v1_5 
codepoints for TLS 1.3 I-D to them.

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

[TLS]Re: Working Group Last Call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

[Andrei Popov]

+1 what Rich said. Not a deal-breaker for me either way, but I would prefer 
"N", initially.

Cheers,

Andrei

-Original Message-
From: Salz, Rich  
Sent: Wednesday, May 22, 2024 7:26 AM
To: Sean Turner ; TLS List 
Subject: [EXTERNAL] [TLS]Re: Working Group Last Call for Legacy 
RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

> This email starts the working group last call for "Legacy RSASSA-PKCS1-v1_5 
> codepoints for TLS 1.3” I-D, located here:

No comments, ship it.

> The only comment/question I have about this I-D (and I hope this is not too 
> much of a bikeshed) is whether the Recommended column should be “D” instead 
> of “N”.

I think that would be a mistake as it makes the vast deployment of existing TPM 
machines nonconformant.  In a few years, maybe. For now, not-recommended is 
strong enough.


___
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: Working Group Last Call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

[Sean Turner]

> On May 22, 2024, at 10:28, David Benjamin  wrote:
> 
> On Wed, May 22, 2024 at 10:27 AM Salz, Rich 
>  wrote:
> > This email starts the working group last call for "Legacy RSASSA-PKCS1-v1_5 
> > codepoints for TLS 1.3” I-D, located here:
> 
> No comments, ship it.
> 
> > The only comment/question I have about this I-D (and I hope this is not too 
> > much of a bikeshed) is whether the Recommended column should be “D” instead 
> > of “N”.
> 
> I think that would be a mistake as it makes the vast deployment of existing 
> TPM machines nonconformant.  In a few years, maybe. For now, not-recommended 
> is strong enough.
> 
> (I don't have strong feelings on this and am happy to defer this to what 
> everyone else wants. Just briefly noting that "N" in the document isn't an 
> explicit preference here. "D" just didn't exist at the time the document was 
> written.)

I figured this was the case.  Part of the reason for raising this point now is 
to tell the IESG that we actually thought about it when somebody asks about 
whether we considered “D”.

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

[TLS]Re: Working Group Last Call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

[David Benjamin]

On Wed, May 22, 2024 at 10:27 AM Salz, Rich  wrote:

> > This email starts the working group last call for "Legacy
> RSASSA-PKCS1-v1_5 codepoints for TLS 1.3” I-D, located here:
>
> No comments, ship it.
>
> > The only comment/question I have about this I-D (and I hope this is not
> too much of a bikeshed) is whether the Recommended column should be “D”
> instead of “N”.
>
> I think that would be a mistake as it makes the vast deployment of
> existing TPM machines nonconformant.  In a few years, maybe. For now,
> not-recommended is strong enough.
>

(I don't have strong feelings on this and am happy to defer this to what
everyone else wants. Just briefly noting that "N" in the document isn't an
explicit preference here. "D" just didn't exist at the time the document
was written.)

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

[TLS]Re: Working Group Last Call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

[Salz, Rich]

> This email starts the working group last call for "Legacy RSASSA-PKCS1-v1_5 
> codepoints for TLS 1.3” I-D, located here:

No comments, ship it.

> The only comment/question I have about this I-D (and I hope this is not too 
> much of a bikeshed) is whether the Recommended column should be “D” instead 
> of “N”.

I think that would be a mistake as it makes the vast deployment of existing TPM 
machines nonconformant.  In a few years, maybe. For now, not-recommended is 
strong enough.


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

[TLS]Re: Working Group Last Call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

[Sean Turner]

> On May 22, 2024, at 10:14, Sean Turner  wrote:
> 
> This email starts the working group last call for "Legacy RSASSA-PKCS1-v1_5 
> codepoints for TLS 1.3” I-D, located here:
> 
> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-pkcs1/
> 
> The WG Last Call will end 5 June 2024 @ 2359 UTC.
> 
> Please review the I-D and submit issues and pull requests via the GitHub 
> repository that can be found at:
> 
> https://github.com/tlswg/tls13-pkcs1
> 
> Alternatively, you can also send your comments to tls@ietf.org.



The only comment/question I have about this I-D (and I hope this is not too 
much of a bikeshed) is whether the Recommended column should be “D” instead of 
“N”.



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

[TLS]Working Group Last Call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

[Sean Turner]

This email starts the working group last call for "Legacy RSASSA-PKCS1-v1_5 
codepoints for TLS 1.3” I-D, located here:

https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-pkcs1/

The WG Last Call will end 5 June 2024 @ 2359 UTC.

Please review the I-D and submit issues and pull requests via the GitHub 
repository that can be found at:

https://github.com/tlswg/tls13-pkcs1

Alternatively, you can also send your comments to tls@ietf.org.

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

[TLS]progressing -rrc

[Sean Turner]

Hi! If you recall we paused progressing -rrc [1] while we awaited 
implementations.  Well, we now have that; we have one server and two clients 
(all DTLS 1.2) [2]. However, we now also have the formal analysis triage panel 
so we need to run the I-D through them.  Once we run the I-D through that 
process we will revisit progressing the I-D.  I [have noted / will note] in the 
datatracker that the document is awaiting external review.

Cheers,
spt

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-rrc/
[2] https://github.com/tlswg/dtls-rrc/issues/72
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: WG Adoption for TLS Trust Expressions

[Watson Ladd]

On Tue, May 21, 2024 at 4:56 PM David Benjamin 
wrote:
>
> Hi Richard. Thanks for the comments! Replies inline.
>
> On Mon, May 6, 2024 at 10:23 AM Richard Barnes  wrote:
>>
>> Hi all,
>>
>> Coming in late here.  Appreciate the discussion so far.  FWIW, here's
how I'm thinking through this:
>>
>> I would frame the basic problem here as follows, since I think the use
cases presented are all basically corollaries: Root store fragmentation
makes it hard for server operators to make sure they can authenticate to
all of the clients they want to connect with.  Note that the pain is
non-zero regardless of technology.  The more clients have differing
requirements, the more work servers are going to have to do to support them
all.
>>
>> Pain = (Amount of fragmentation) * (Pain per fragmentation)
>>
>> The question at issue here is how trust expressions affect the inputs to
this equation.
>>
>> Shifting from a single-certificate to a multi-certificate world shifts
the pain, from "How do I pick the most widely accepted cert?" to "How do I
make sure I have the right selection of certificates?"  I probably agree
that this is a net reduction in pain for a given level of fragementation.
>
>
> I think we’re broadly in agreement here. Fragmentation exists today, both
between different root programs and between versions of a given client and
there is a significant amount of pain involved for affected server
operators with no option but to find a new ubiquitously-trusted CA and
reissue.
>
> We’re particularly concerned about this server operator pain because it
translates to security risks for billions of users. If root program actions
cause server operator pain, there is significant pressure against those
actions. The end result of this is that root store changes happen
infrequently, with the ultimate cost being that user security cannot
benefit from PKI improvements.
>
> It’s worth noting that, for a given set of target clients, picking the
most widely accepted certificate is not merely painful but potentially
infeasible. Picking a larger selection of certificates allows the server
operator to meet their needs. There is still some cost to selecting from
too many certificates, but trust expressions greatly relieves the pressures
that, again, ultimately are paid by user security.
>
> We also anticipate many of those costs can be mitigated by instead
imposing smaller costs on CAs, who already have existing relationships with
root programs. Indeed, CAs already make decisions about supported clients,
by deciding which cross-signs and intermediates to include and which to
retire. Trust expressions makes these decisions more explicit.

I'm sort of confused here. As I understood it Trust Expressions
communicates from the client to the server what CAs the client would
accept, and lets the server that would have two separate certs from
different roots serve the union of the clients that accept each one easily.
I'm not sure how that imposes costs on CAs. Furthermore I'm not entirely
sure how much it helps in the case of distrust. The server still needs to
acquire new certificates unless the ones it has cover the set of clients
even post the distrust.

What really reduces the cost here is automation in changing to a more
commonly supported root easily. Even after Trust Expressions that
automation is required now to maintain a covering set, while before it's a
covering set of size one.

The decisions Trust Expressions communicate aren't CA decisions either. The
cross-signed intermediate on the server is sent back in the chain and
extends the reach of the root that the client trusts. I'm just confused.

I think there's a way where the problem we're trying to solve has been
defined narrowly enough to make Trust Expressions the right solution, but
the problems that server operators and users care about are a bit higher
level.

>
>>
>> I probably also agree with Dennis, though, that reducing the pain at a
given level of fragmentation will increase the temptation to more
fragmentation.  The country-level stuff is there, but even some of the
putative use cases look like more fragmentation -- more algorithms,
changing root store policies more frequently.  Playing the combinatorics
out here, how many certs is a server going to have to maintain?
>
>
> To some degree, yes, we want to increase fragmentation when it is
necessary to benefit user security. Fragmentation is an inherent
consequence of root program changes, and root programs often need changes
to meet user security (and, with post-quantum, performance) needs, but the
costs today are prohibitive to the point that root programs cannot
effectively meet those needs.
>
> Of course, unnecessary fragmentation is undesirable. Trust expressions
fixes the prohibitive costs but, as you allude to, there are still costs.
We don’t want servers to need to maintain unboundedly many certificates.
However, note that these same costs are pressure against excessive,
unnecessary fragmentation.
>
> It’s 

[TLS]Re: WG Adoption for TLS Trust Expressions

[Nick Harper]

On Tue, May 21, 2024 at 3:00 PM Dennis Jackson  wrote:

> This thread is now 40+ messages deep and I guess you might have not seen
> much of the previous discussion. I actually agree with much of your
> analysis, but it focused on the wrong question, as I wrote earlier in this
> thread:
>
> The question we're evaluating is NOT "If we were in a very unhappy world
> where governments controlled root certificates on client devices and used
> them for mass surveillance, does Trust Expressions make things worse?"
> Although Watson observed that the answer to this is at least 'somewhat', I
> agree such a world is already maxed at 10/10 on the bad worlds to live in
> scale and so it's not by itself a major problem in my view.
>
> I don't see Watson saying that in any of his messages [5] [6] [7]. Message
[7] does mention an intermediate cross-signed by a government CA, but my
understanding of Watson's argument is that Trust Expressions doesn't do
anything to enable that since the "chain" of certificates sent by a TLS
server is really just a grab bag for the client to use when it does path
building. Specifically, in today's world, a CA could send to ACME clients a
leaf cert with intermediates and cross-signs so that the root of the path
could be either that CA or a government CA, and when that server sends that
bag of intermediates to a client to verify, the client will build one of
those two paths, depending on what's in the client's trust store.

>
> The actual concern is: to what extent do Trust Expressions increase the
> probability that we end up in this unhappy world of government CAs used for
> mass surveillance?
>
> This is a good question to ask, and I see you attempted to address it in
message [4]. You argue that Trust Expressions provides an "on-ramp" for
deploying a government CA to reach a certain level of legitimacy or
adoption. I don't see the connection between that and mass surveillance,
nor do I see you make a claim that Trust Expressions does increase this
probability. In [1] you describe this "on-ramp", which has step 1 being to
ship support for trust negotiation (which could be more accurately
described as a trust store advertisement mechanism), and step 2 as the
following:

>  * A large country or federation pushes for recognition of their
>domestic trust regime as a distinct trust store which browsers must
>advertise. Browsers agree because the relevant market is too big to
>leave.

I see two ways this happens: The first is that the recognition of the
domestic trust regime is done in a way that does not circumvent root store
policy. By this, I mean that the CAs in this domestic trust regime must
meet all audit and other policy requirements of the browser's root store,
and a brower root store can remove trust in a CA from that set if it
violates the root store requirements (in the same way that root stores
currently operate to distrust a CA when it is no longer trustworthy). In
this case, I see no negative effect on security for users or the websites
they are connecting to. From a technical perspective, this looks the same
regardless of whether the Web PKI ecosystem supports a trust store
advertisement mechanism. I see no change in the probability of ending up in
the "unhappy world" in this way.

The second way this could happen is that the government compels a browser
to add a CA to their root store regardless of whether it complies with root
store policy, implicitly stating that this CA will misissue certificates.
The browser's choice is to comply or leave the market. Until this new CA is
in a trust store advertised by clients, there's no incentive for server
operators to get a certificate issued by that CA, as there are no clients
for it to present that cert to. Thus, server adoption is no factor in the
government's pressure to compel a browser to add their CA, and I see the
same probability of this being successful as in the current state of the
world without Trust Expressions.

There is potentially a hybrid approach, where the government first asks
nicely that browsers add CA G to their root stores (where root stores are
welcome to remove G if it violates policy). At some later point in time,
the government tells browsers that since now G is already in their root
stores, they're not allowed to remove it, and at some point later G starts
mis-issuing certificates to perform surveillance or do other bad things.
This switcheroo looks the same in today's world as it does in a world with
a trust store advertisement mechanism. In a world without trust
expressions, the government gets G added to all major browser root stores,
then starts doing bad things with G when it's rolled out to enough
browsers. Doing bad things with G requires no server adoption. In a world
without trust store advertisements, the government can still
compel/coerce/encourage site operators to use a cert issued by G, by using
the mechanism that Watson described and is repeated above that requires no
changes to