On Wed, Jun 12, 2024 at 5:16 PM Nick Harper <i...@nharper.org> wrote:
> On Wed, Jun 12, 2024 at 3:17 AM Dennis Jackson <i...@dennis-jackson.uk>
> wrote:
>
>> You can't argue that T.E. contains the functionality of
>> certificate_authorities as a subset, then conclude that having additional
>> functionalities makes it less risky. You would need to argue the exact
>> opposite, that T.E. doesn't contain the bad functionalities of
>> certificate_authorities. The risk associated with abuse of a feature is not
>> in any way diluted by tacking on good use cases.
>>
> I'm not arguing that TE is a superset of certificate_authorities. I'm
> arguing that it's an incremental improvement over certificate_authorities.
> That is to say, certificate_authorities is a way for a relying party to
> indicate to a subscriber which CAs it trusts, and TE is another way to do
> the same thing. TE is an incremental improvement because it's solving the
> same problem but making different tradeoffs. To deploy the
> certificate_authorities extension, no extra machinery is needed past what's
> in the certificates, but that comes at a cost of a large number of bytes
> sent by the relying party. TE optimizes for size, at the cost of additional
> complexity and machinery involving additional parties.
>
> For the abuse scenario, TE makes it no easier than certificate_authorities
> (the size of advertising the single malicious CA isn't a concern, whereas
> it is a problem when it's a browser's entire trust store that's
> advertised), and TE adds additional deployment complexity compared to
> certificate_authorities, which lessens the risk.
>
I'm not sure that this analysis is correct. The text in 8446 isn't entirely
clear, but I think the
best reading is that that "certificate_authorities" list is supposed to be
exhaustive:
The "certificate_authorities" extension is used to indicate the
certificate authorities (CAs) which an endpoint supports and which
SHOULD be used by the receiving endpoint to guide certificate
selection.
...
authorities: A list of the distinguished names [X501] of acceptable
certificate authorities, represented in DER-encoded [X690] format.
These distinguished names specify a desired distinguished name for
a trust anchor or subordinate CA; thus, this message can be used
to describe known trust anchors as well as a desired authorization
space.
I don't know how widely implemented this extension is, but I don't think
it's
obviously safe to send a subset of the list.
-Ekr
> The takeaway here is that the risks associated with the abuse of Trust
> Expressions also exist with certificate_authorities.
>>
>> I wonder what such a trust store manifest would look like... [1] [2].
>> There's at least one large player out there with a list of CAs ready to go
>> and all the necessary machinery in place.
>>
> Ready to go and do what?!
>
> If you're talking about the EU eIDAS QWAC trust list, those CAs were
> already trusted by browsers before the eIDAS regulations took effect, and
> eIDAS allows for their distrust and removal. Already, one CA [1] on that
> list is being distrusted by multiple [2] browsers [3]. Even if the EU has a
> published list of CAs that they could turn into a trust store manifest,
> this is a distraction from the point that with TE, abuse requires the
> cooperation (or compulsion) of more parties than with
> certificate_authorities.
>
> 1: https://eidas.ec.europa.eu/efda/tl-browser/#/screen/tl/AT/5/25
> 2:
> https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/XpknYMPO8dI/m/JBNFg3aVAwAJ
> 3:
> https://groups.google.com/a/ccadb.org/g/public/c/wRs-zec8w7k/m/G_9QprJ2AQAJ
>
> _______________________________________________
> 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
