On Sat, Jul 20, 2024 at 2:23 PM David Benjamin <david...@chromium.org> wrote:
> On Sat, Jul 20, 2024, 06:13 Mike Shaver <mike.sha...@gmail.com> 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 <ietf= 40dennis-jackson...@dmarc.ietf.org> 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 <david...@chromium.org> wrote: > On Sat, Jul 20, 2024, 06:13 Mike Shaver <mike.sha...@gmail.com> wrote: > >> >> >> On Sat, Jul 20, 2024 at 8:59 AM Ilari Liusvaara <ilariliusva...@welho.com> >> 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
